Re: pessimal storage allocation, Continuations

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.

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.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly