[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Mar 29 16:42:58 2000 
Subject:Re: FWD: from Jonathan Cunningham about Macintosh implementations 
From:Aaron Sloman See text for reply address 
Volume-ID:1000329.07 

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Jonathan L Cunningham wrote

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

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

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

More reminiscences:

This method, which involves putting objects of the same type and
size in the same "cage" in the address space, and then all
variable-sized objects (strings, vectors, functions, etc.) in a
separate heap, was also used for a while in the system called
WonderPop (wpop) implemented by Robert Rae (later joined by Allan
Ramsay) in the Edinburgh University AI department, on the
DEC-10 DEC-20 computers. I believe wpop was widely used on
DEC-10 and 20 computers for several years.

I remember using wpop for a few years in the late 70s, via a 1200 bd
connection from Sussex to a time-shared computer in Edinburgh with
about 0.5 MWords memory. Each 36 bit word contained two 18 bit
addresses, so we didn't have 8-bit bytes, etc. The system had many
nice features, including the option of having typed integer or
decimal variables or arrays, and an optimiser which could take
account of the typing. Incrementally compiled wpop on that system
ran as fast as compiled Pascal, on simple arithmetic tasks. I think
wpop was the first pop system with properties (hash tables).

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

The worst problem I remember with caging was that you had to decide
in advance of starting up wpop how much address space to allocate to
each "cage" (list cells, references, other record classes etc.) and
if you ran out of space in a cage, you had to start again with a
bigger guess.

It was partly experience with that system that led me to argue
against the use of caged memory when we discussed it in the early
days of poplog.

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

Nice argument.

In the early days of poplog there were several issues that arose
about whether to use an implementation that saved space, at the cost
of speed or convenience or simplicity of implementation. We always
argued that memory would become cheaper.

So, for example, we rejected the idea of tagged addresses for lists
which at one time were popular in Lisp implementations. Their
designers then cursed when more addressable memory became available
and they had to use a full word as an address, requiring a major
re-implementation.

Another less obvious point is the large collection of strings for
error messages in the poplog system source files, e.g. things
like this in $popsrc/list_hdtl.p

    mishap(item, 1, if item == [] then 'NON-EMPTY LIST NEEDED'
                    else 'LIST NEEDED' endif)

We discussed moving all those hundreds of strings out into a file,
with numbers or labels and having an error mechanism which found the
appropriate string when an error occurred. We decided against that
on the grounds that it would add significantly to
development/maintenance costs and was inherently seriously
error-prone unless supported by software tools that we were too busy
to consider developing.

There was also the thought that maybe the Virtual memory system
would achieve the same effect anway, if all those system strings
were mainly in pages that mostly remained paged out.

Two further (minor) comments:

(a) the space/speed dimensions may seem to be orthogonal but I
learnt from bitter experience that if I went for speed and that
increased space, it could also cause more paging which then had a
dreadful effect on speed. (I built an index to a database to avoid
linear searches through a long list. The extra size of the index and
its associated procedures triggered paging, so that linear searches
were much faster. Disks were much slower in those days.)

(b) Another dimension which can interact with speed and space is
reliability or robustness which will often be related to simplicity
of design (and therefore maintenance). In general if a gain in space
or speed adds significantly to complexity, or reduces
intelligibility of the code, always think hard before you do it!

Some American Lisp implementations in the late 80s (and maybe later)
also seemed to disregard space issues: they seemed to require far,
far, more memory than the combination of pop-11 and common lisp
needed in Poplog. I never knew why.

Cheers.
Aaron
==