a missing part of the ack source

[u-l...@aetey.se]

Hello,

Looking at the binary media of Minix-2.0.4 for i86 one can see
in USR.TAZ the presence of lib/irrel, dated 26th December 2000.

The ack compiler driver uses this file as one of the passes,
src/commands/i86/cc.c refers to it.

Unfortunately there are no traces of a source file for irrel
in any of the ack, tack, ackpack source archives which I was able
to locate.

Is it possible to recover this missing piece of the source? It looks
necessary to be able to run ack on 16-bit hardware, a comment in cc.c says
/* A .c file must always be mishandled by irrel. */

The minix-vmd cc man page seems to be the only documentation
which tells about the purpose of the pass:
"lib/irrel prog.i prog.i Removal of unnecessary prototypes"
and says that it helps
"If the compiler runs out of memory"
and
"you should only run this pass as a last resort"

On 16-bit the memory pressure is harder and this pass is apparently
not optional, despite its side effects.

I hope the persons who were involved in building the named installation
media are possibly reading this forum or can be reached, somehow.

Which source was the irrel pass binary built from? Can it be recovered?

TIA,
Rune

[Antoine LECA]

On 19/11/2016 20:24Z, u-l...@aetey.se wrote:
> Looking at the binary media of Minix-2.0.4 for i86 one can see
> in USR.TAZ the presence of lib/irrel, dated 26th December 2000.
>
> The ack compiler driver uses this file as one of the passes,
> src/commands/i86/cc.c refers to it.
>
> Unfortunately there are no traces of a source file for irrel
> in any of the ack, tack, ackpack source archives which I was able
> to locate.

I do not have the updated version made in 2000 for 2.0.3 (noted in the
changes.txt file); I guess Kees or perhaps Philip _could_ have it in
their backups; but I do not know if they are reading this list.

I once spotted a version of it in the ACK (5.2) source; it is a version
from 1991 (probably the same as used for MINIX 1.6, 2.0.2 and 2.0.2: the
CVS tree it came with was dated 1996.) Attached.

> Is it possible to recover this missing piece of the source? It looks
> necessary to be able to run ack on 16-bit hardware, a comment in cc.c says
> /* A .c file must always be mishandled by irrel. */

It is not *necessary*, just helpful. The purpose of irrel is to remove
the "irrelevant" prototypes. That way, you can feed to the (K&R) 16-bit
compiler with sources having prototypes in the headers.

That trick was proposed IIUC by Wietse Venema (of Postfix fame), which
later developed the unproto package which is standalone. The MINIX guys
(AST according to the source) picked up the idea and integrated it
inside the compiler, calling the irrel pass on the fly between
preprocessor (which does understand ANSI CC even in its 16-bit
implementation) and the 'ccom' main compiler (which in its 16-bit
compiled form cannot understand the full standard while staying inside
the 64KB frame, at least for not-trivial source files.)

Once you are running ACK on any 32-bit platform, irrel is completely
unnecessary; unless you plan to use the unsupported "old" compiler, but
I do not believe the complete source for it have been made available.

And even if you are on the MINIX-86 platform, perhaps planning to
rebuild MINIX 2.0.x *from scratch* (M86FS.org, sounds nice ;-) ), then I
guess you'll find more required stuff is missing: last time I tried, I
was not able to rebuild a i86-on-i86 ACK compiler with the public
sources salvaged in 2005; and ackpack specifically targets 32-bit
machines (mainly 2.0.x, 3.0.x or 3.1.x MINIX-386.)

> I hope the persons who were involved in building the named installation
> media are possibly reading this forum or can be reached, somehow.
>
> Which source was the irrel pass binary built from? Can it be recovered?

It is my understanding Kees' hard disk suffered a serious failure at one
point, and some content were definitively lost then; I do not know if it
applies to ACK sources as used for MINIX 1.6-to-2.0.4 (or VMD). Perhaps
I am wrong (I hope so!) and all that stuff can be resurfaced.


Antoine

[u-l...@aetey.se]

On Sun, Nov 20, 2016 at 03:53:58PM +0100, Antoine LECA wrote:
> I once spotted a version of it in the ACK (5.2) source; it is a version
> from 1991 (probably the same as used for MINIX 1.6, 2.0.2 and 2.0.2: the
> CVS tree it came with was dated 1996.) Attached.

Many thanks! I guess it will do as-is or at least it shows what the pass
was supposed to do and can be fixed if necessary.

> That trick was proposed IIUC by Wietse Venema (of Postfix fame), which
> later developed the unproto package which is standalone.

Yes, unproto was helpful with old compilers.

> And even if you are on the MINIX-86 platform, perhaps planning to
> rebuild MINIX 2.0.x *from scratch* (M86FS.org, sounds nice ;-) ), then I
> guess you'll find more required stuff is missing: last time I tried, I
> was not able to rebuild a i86-on-i86 ACK compiler with the public
> sources salvaged in 2005

:(

> It is my understanding Kees' hard disk suffered a serious failure at one
> point, and some content were definitively lost then; I do not know if it
> applies to ACK sources as used for MINIX 1.6-to-2.0.4 (or VMD). Perhaps
> I am wrong (I hope so!) and all that stuff can be resurfaced.

Was ACK self-hosting on 16-bit at that time or was it cross-built for 16-bit
Minix on more powerful machnes?

Thanks Antoine.

Rune

[Philip Homburg]

>I do not have the updated version made in 2000 for 2.0.3 (noted in the
>changes.txt file); I guess Kees or perhaps Philip _could_ have it in
>their backups; but I do not know if they are reading this list.

Here is some historical background (at least the way I remember it):

ACK was a research project at the VU that was turned into a commercial product.
For while it made quite a bit of money, which as used to fund all kinds of
things for computer science at the VU.

MINIX was a private project of Andy.

Andy got permission to use ACK for the MINIX C compiler, but he could only ship
the binaries.

The ACK ANSI-C compiler was way too big to run on 16-bit MINIX, so the programmer
that the VU who worked on ACK created a special hacked version that was small
enough to run.

Even then, the compiler would run out of memory, hence irrel.

When the ANSI-C compiler was first relased for MINIX, it was an optional extra
that you had to buy. So those source were kept separate for MINIX.

Later, when the ACK sources were released, there was not a lot of knowledge
on how to build them. A few people knew the ACK build process and MINIX
distribution would usually include the compiler binaries.

As for me, I lost interest in 16-bit MINIX as soon as I had a 386. So I
never bothered to get copies of all the ACK parts that were specific to 16-bit
MINIX.

[u-l...@aetey.se]

On Mon, Nov 21, 2016 at 02:45:33PM +0100, Philip Homburg wrote:
> Here is some historical background (at least the way I remember it):

Thanks Philip!

> The ACK ANSI-C compiler was way too big to run on 16-bit MINIX, so the programmer
> that the VU who worked on ACK created a special hacked version that was small
> enough to run.
>
> Even then, the compiler would run out of memory, hence irrel.

A nice workaround, compared to applying unproto externally
or resorting to K&R.

> Later, when the ACK sources were released, there was not a lot of knowledge
> on how to build them. A few people knew the ACK build process and MINIX
> distribution would usually include the compiler binaries.

Now many years later this build knowledge seems to be recovering, at least
partially.

> As for me, I lost interest in 16-bit MINIX as soon as I had a 386. So I
> never bothered to get copies of all the ACK parts that were specific to 16-bit
> MINIX.

This is understandable.

OT:
Nevertheless it would be fun to revive the 16-bit OS.
Moreover, a simpler CPU incurs less damage on the environment than a
complex one, if produced with the same technology. For suitable tasks it
quite certainly consumes less energy for the computations. Less memory
involved also means less power to supply. More compact software can
also be made more reliable. Thus, for a suitable task, 16-bit easily
qualifies as the best choice :)

Regards,
Rune