[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scheme broken on OZ today.
- To: RWK at SCRC-TENEX
- Subject: Re: Scheme broken on OZ today.
- From: David C. Plummer <DCP at MIT-MC>
- Date: Sun, 21 Nov 82 03:25:00 GMT
- Cc: GJC at MIT-MC, GLR at MIT-OZ, FEINBERG at MIT-OZ, HAL at MIT-OZ, GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ
- Original-date: 20 November 1982 22:25-EST
You want to make separate code and data spaces for the current
MACLISP, do you?? Well, FORGET IT!!! Perhaps you should get
Gorin's book on TWENEX assembler and read the section on extended
Basically, CAR and CDR won't work. Well, it might have a prayer
if the CODE for CAR and CDR were in the DATA section. This goes
for all other code that does a CAR or CDR. Well, then again, you
might be able to get around that by making CAR and CDR be two
instructions instead of one. The second instruction would set
the left half to be the DATA section. Kludge, kludge, kludge.
Now what about all those other primitive LISP operators??
That is not the right solution. The right solution is to
reimplement 'Lisp' for extended addressing machines. For 2060's
this would give you 31 address spaces (assuming you can't do much
useful stuff in section 0). On the Jupiter I think the number
jumps to 4095 (and then all you need is several dozen disk drives
I know of at least one effort to write an extended addressing
superset of Common Lisp. How much MACLisp code will need to be
modified or rewritten probably depends on how well it was written
for portability in the first place.
My feable knowledge of Common Lisp forces me to make the
* Expect your programs to get bigger. CONSes will take up two
words instead of one.
* Fixnums may shrink to 32 (or even 30) bits. Overflow will cons
* Expect arithmetic operations to slow down. I think Common Lisp
does generic arithemetic. If so, a simple + on non-declared
numbers needs to check the arguments and value (even in compiled