Re: pessimal storage allocation, Continuations

On Mon, 15 Jul 2024 20:07:10 +0000, John Levine wrote:

According to EricP  <ThatWouldBeTelling@thevillage.com>:

Each current local context could be allocated from a heap.
But be careful what you wish for.
We were playing with an IBM R6000 around 1990 which was supposed to
be this fast risc machine but we found it ran slower than our VAX.
We disassembled the code and found out that instead of a normal
decrement/increment stack it used a linked list of heap allocated
objects.
Every call did a malloc and every return did a free. All the hardware
speed
improvement had been squandered on this completely unnecessary ABI
overhead.

>
Maybe it was an IBM thing. In the 1960s the IBM 360 Algol F compiler,
which I always assumed was written because some European institution
had it on a checklist rather than because they expected anyone to use
it, did the same thing. Every time it entered a block it did a GETMAIN
system call, and when it left the block it did a FREEMAIN, with all of
the performance you'd expect.

The only thing I can comment on, here, is that 1108 Algol was much
faster than 360/67 Algol.

>
Someone at Princeton patched it to do more sane allocation where it
did a big GETMAIN and suballocated from that until it filled up and
then did another one. I never wrote enough Algol to tell how well it
worked.
>
The compiler was a marvel of passive aggressive standards
implementation.  The
keywords were all quoted 'BEGIN' 'END' and unless you told it otherwise
it used
the 48 charater set so a semicolon was ., and assignment was .= with one
dot,
not two.  A squared was A'POWER'2.  I/O was procedures that used dataset
numbers, 0 was the input deck, 1 was the printer, and you skipped to the
next output record by padding out the current record to 80 spaces.
>
'COMMENT'TOO BAD THEY DID NOT USE 'TNEMMOC'.,
>
Yuck.