Re: is it sensible to think of an extended address Lisp for the DEC-20?

[Guy.Steele at CMU-10A]

I remember all too well worrying about whether to extend MacLISP for
DEC20 extended addressing, when it first was announced (rumored?).
It's been some time, but I'll try to outline here why we (JONL, I, and
whoevere else was around at the time) didn't do it:

(1) There is an obvious problem regarding data formats.  Either you
make pointers larger than 18 bits, or you don'.  If you don't, then
you can only take advantage of the extra address space by filling it
with compled code (which might have been acceptable for MACSYMA),
and additionally you could keep special things like print name strings
outside the "primary" 18-bit address space which pointers can reference.
The reason one might not make pointers bigger is to preserve as much
compatibility as possible with old code (e.g. HLRZ=CAR, HRRZ=CDR).
On the other hand, this doesn't really work either, because as I recall
indexing off a pointer whose LH is zero means "current 18-bit address
space", not "address space zero".  One might use HLRO and HRRO for CAR and
CDR, and make the last 18-bit address space be the one for data, but
already it's getting kludgy.  Also, there's the problem of not being
able to put list-structure constants as immediate data, e.g.
(CAIN B (QUOTE FOO)) as an instruction.
On the other hand, if you make pointers be greater than 18 bits, the
data formats have to change radically; in particular, list cells noiw
occupy two words.  Thus you have already lost a factor of two on space
before beginning to get any back.  This could be expected to have a
severe effect on virtual memory performance, particularly on programs
that didn't need extended addressing anyway, which are many.

(2) After number (1), you want another reason???

The problem is that DEC20 extended addressing is really a kludge,
and it's not a simple question of a smooth upgrading of an existing
LISP system.  We estimated that over half the existing code would
have to be rewritten; given the choice of doing that or holding off
and waiting for the LISP Machine or VAX, the latter seemed more
attractive and profitable.

P.S. I just remembered that using HRRO and HLRO didn't work either,
because DEC20 extended addressing called for ignoring the LH of
an index if the sign bit was set (this was to make indexing off
AOBJN pointers still work, in some sense).  I told you it was a kludge!