[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 29 15:34:08 2000 
Subject:FWD: from Jonathan Cunningham about Macintosh implementations 
From:Aaron Sloman See text for reply address 
Volume-ID:1000429.01 

I thought the Mail->News gateway had been fixed, but this message
did not get through. So I am posting it to comp.lang.pop.
Aaron

Message-ID: <001601bfb1dc$b6842be0$0200a8c0@delia>
From: "Jonathan L Cunningham" <jlc@sofluc.co.uk>
To: <pop-forum@cs.bham.ac.uk>
Subject: Re: Macintosh implementations of Poplog or Pop11
Date: Sat, 29 Apr 2000 14:08:54 +0100

The following may be of historical interest to some people.
And of no interest to others. Decide for yourselves!

>At 11:28 am -0500 28/3/00, Robin Popplestone wrote:
>>I don't know if AlphaPop still works on modern macs I'd rather doubt
>>it. Robin.
>
>Sadly, AlphaPop did not make the transition to the modern memory
>management scheme.  I believe (but this may be rubbish) that they
>exploited the fact that the old Mac O/S could only address 24-bits
>for tagging - and this changed, as it was bound to change, and Cog.
>App. had seen too little financial return to continue.


It seemed like a good idea at the time. I know younger viewers will
find this hard to believe, but typical machines of that era had less
than 1 MB of RAM (20 bits needed for the address space). A typical
home computer might have 128K of RAM (only 17 bits). This was in 1986.

We could expect the 24 bit addressing trick to work for at least
another 6 years, even on Macs which were expensive and tended to have
more memory. I.e. until around 1993. This seemed long enough.

Even so, the code was written using macros so that all "tag" and
address manipulations could (and should) be changed to 32 bit
just by redefining the macros, and changing the memory management.

But no one with experience of s/ware dev. would expect it to
really be that simple!

However, if the intended port to the PC had gone ahead, we would
no doubt have found (and eliminated?) all the places where the
24 bit addressing was implicitly assumed in the code: at that
time addressing models on the PC were horrendous. The flat
address space of the Mac was one of the justifications for
developing on it. (And if you don't know what I mean by PC
address models, be very glad! Does anyone else remember "far"
and "near" pointers?)

[Digression: The justifiction for the 6 year prediction:

Memory doubles every 18 months, approx, and had done for
twenty years. And it did continue to do so for the next 14; it still
continues. We might expect the typical home machine in 2001 to have
around 128 MB of RAM. 1 GB of RAM won't be the norm (for a
home machine) until around 2005/2006. Extrapolating backwards,
a typical "home computer" in 1971 should have around 128 bytes
of memory, i.e. 1/8th of a K. This is about right.

Serious hobbyists, of course, have machines a year or two ahead
of the "typical" machine.
]

The tagged address idea was a memory saving compromise, part of
a space/speed trade-off. We wanted to avoid using 12 bytes per
list cell, as is done in poplog and (I believe, but I haven't
looked at the latest version) in Franz Allegro Lisp for PCs.

Space was a very important concern, particularly since there was
no virtual memory.

To see why this is significant, the pop11 database:

  [[felix drinks milk]
   [fido drinks water]] -> database;

would take 96 bytes of list-cell space in poplog, but only 64
bytes at 8 bytes per list-cell, i.e. you could work with 50%
more list data. This mattered.

However, the Macintosh Lisp of around that time (c. 1990) used
a better idea, and (again, if memory serves) only required
8 bytes per list cell, without using tags. The trick is to
use separate areas of memory for list cells versus everything
else. (Actually, if you are going to do that, then you may as
well have separate areas for a few other things as well, such as
storage which cannot contain pointers, e.g. strings.) This would
make memory management (particularly the garbage collector) a
lot more complicated, and there are other costs, but it would
probably have been a better choice.

[Another digression:

Another problem with Alphapop was its speed. Some parts of
it were very fast, but many other parts were slow. This didn't
affect many potential users, but it did matter to a sizeable
proportion of them. There was no single reason why it was slow,
but more a combination of a number of trade-offs.

With hindsight, it is easy to see that in a space/speed trade-off
you should generally go for speed. Because the space problem
solves itself (at a factor of 2 approx every 18 months) and any
speed gains are still a benefit however much faster machines
get.]

Jonathan