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

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

On Sunday, 9 January 2022 at 13:14:53 UTC-7, Janis Papanagnou wrote:
> 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
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!

On 1/10/2022 11:17 AM, Jeff Paranich wrote:
> On Sunday, 9 January 2022 at 13:14:53 UTC-7, Janis Papanagnou wrote:
>> 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
> 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!

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.

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.

On 2022-01-11, Janis Papanagnou <janis_papanagnou@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.

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.

>
> 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.
>

On 11.01.2022 18:37, Kaz Kylheku wrote:
> On 2022-01-11, Janis Papanagnou <janis_papanagnou@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.

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

In article <srffnr$mbr$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>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.

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,

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

On 13.01.2022 21:00, Aharon Robbins wrote:
> In article <srffnr$mbr$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>> 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.
>
> 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?

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
>

In article <srqde2$u86$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou@hotmail.com> wrote:
>> 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?
>
>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.

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.

Thanks,

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