awkcc available, again

[Aharon Robbins]

Hello All.

I am pleased to announce that, after a multi-year effort, Chris Ramming's
awkcc is now once again available for download, and this time with
a more permissive license.

(It was made available in 2011 under a personal use license, and over
time it disappeared as Bell Labs changed owners and management.)

The code, both the 1988 and 2011 versions, may be found at
https://github.com/nokia/awkcc.

The code is primarily of historical interest; I think it would take
a significant effort to build it on a more modern system, although I
think it could be done. It'd also be an effort to bring it up to date
with the current Unix version of awk. Again most likely doable, but not
necessarily trivial.

In any case, enjoy!

Arnold
--
Aharon (Arnold) Robbins arnold AT skeeve DOT com

[Janis Papanagnou]

On 09.01.2022 20:29, Aharon Robbins wrote:
> [...]

> https://github.com/nokia/awkcc.
>
> The code is primarily of historical interest; I think it would take
> a significant effort to build it on a more modern system, although I
> think it could be done.

It compiles on my system with warnings but creates an awkcc executable.

The strange thing is that calling it creates an error because it wants
to run the awkcc.sh script (which is non-executable per default). It's,
I think, the first time that I've seen such a design.

Janis

[Jeff Paranich]

Hi everyone.... Arnold thanks for the notification.

Ironically I had stumbled on this source a year ago and reach out to Nokia/Bell folk if I could release it, but nobody was sure... so I held off. I had it compiling with a few fixes and have been using it for personal use since then.

I've released a fork of Nokia's repo with my build files. Actually my source copy had various folders not part of your release Robin, so I've essentially just merged it all.

My repo can be found here: https://github.com/chipnetics/awkcc

I'll try to add more details as time allow. Thanks again!

[Ed Morton]

Have you found much of a speed improvement after compiling the C version
of the scripts that awkcc outputs? When I worked at AT&T in the 90s we
used fairly large (1,000+ lines) awk scripts with nawk for some C code
generation from a domain-specific language and tried using awkcc to let
us compile our awk scripts to speed up the build process but didn't
notice a difference.

Ed.

[Janis Papanagnou]

On 11.01.2022 15:05, Ed Morton wrote:
>
> Have you found much of a speed improvement after compiling the C version
> of the scripts that awkcc outputs? When I worked at AT&T in the 90s we
> used fairly large (1,000+ lines) awk scripts with nawk for some C code
> generation from a domain-specific language and tried using awkcc to let
> us compile our awk scripts to speed up the build process but didn't
> notice a difference.

This observation astonishes me, I'd have expected at least *some*
speed up for a compiled version, yet more so for the not too fast
Nawk. - Is the generated code so bad?

Around 1999 there was the Awka Awk-compiler, and on it's web page[*]
they have some performance data - not standard test cases, rather
just measuring the runtime of Awk features - and that compiler works
quite efficient, especially if compared to nawk (which incidentally
was one of the tools used for comparison[**]).

Janis

[*] Still accessible: http://awka.sourceforge.net/compare.html

[**] The used tools don't reflect the current tools' performance;
at that time Gawk (for example) didn't use byte code, so current
Gawk probably competes better than depicted in the these numbers.

[Kaz Kylheku]

On 2022-01-11, Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 11.01.2022 15:05, Ed Morton wrote:
>>
>> Have you found much of a speed improvement after compiling the C version
>> of the scripts that awkcc outputs? When I worked at AT&T in the 90s we
>> used fairly large (1,000+ lines) awk scripts with nawk for some C code
>> generation from a domain-specific language and tried using awkcc to let
>> us compile our awk scripts to speed up the build process but didn't
>> notice a difference.
>
> This observation astonishes me, I'd have expected at least *some*
> speed up for a compiled version, yet more so for the not too fast
> Nawk. - Is the generated code so bad?

If the Awk code is spending most of its time in the host
implementation's run-time support code for input reading and field
splitting, and the compiled Awk doesn't have that aspect well-optimized,
it could end up slower.

[Ed Morton]

On 1/11/2022 10:59 AM, Janis Papanagnou wrote:
> On 11.01.2022 15:05, Ed Morton wrote:
>>
>> Have you found much of a speed improvement after compiling the C version
>> of the scripts that awkcc outputs? When I worked at AT&T in the 90s we
>> used fairly large (1,000+ lines) awk scripts with nawk for some C code
>> generation from a domain-specific language and tried using awkcc to let
>> us compile our awk scripts to speed up the build process but didn't
>> notice a difference.
>
> This observation astonishes me, I'd have expected at least *some*
> speed up for a compiled version, yet more so for the not too fast
> Nawk. - Is the generated code so bad?

It's been about 30 years so I don't remember much about it other than
that the generated code was pretty unreadable (which is not a problem as
long as you don't have to read/modify it!) so we didn't bother trying to
figure out if/where the issues were with it and instead just left the
code as awk.

Ed.

[Janis Papanagnou]

Yes, it was more a rhetorical question; I'd just expected that the core
awk functions/code would be the first parts considered for optimization.
With that in mind I'm wondering whether that would really be the reason
in the case of awkcc. (Not that I'm too concerned about a tool that had
been said to be "primarily of historical interest".)

Janis

[Aharon Robbins]

In article <srffnr$mbr$1...@dont-email.me>,

What happens if you make awkcc.sh executable and put in your PATH?
Do you end up being able to compile and awk program into C and
then compile that and run it?

Thanks,

[Janis Papanagnou]

I didn't want to do that before understanding what I actually do and
what that is that I'd execute. Instead I had looked into some of the
created files and noticed still a couple of hard coded paths in some
of the files which just don't exist (or don't need to exist) in that
way. What I want to say here is that there's more amiss in the package
than just a missing executable flag, and that you have been correct
with your original statement "It'd also be an effort to bring it up
to date", though not in the make process - a C-file had been created,
IIRC - but in the faulty runtime (or its generation). Together with
the arguable design philosophy I'd rather abstain from putting more
effort in that tool.

Janis

>
> Thanks,
>
> Arnold
>

[Aharon Robbins]

In article <srqde2$u86$1...@dont-email.me>,

OK, that's all understandable.

The main point of getting it released was for the historical
value. It was an interesting program that I didn't want to
get lost in the sands of time.