Make LispM code FREE (fwd)

[P. T. Withington]

On 4/1/98 15:22, William A. Barnett-Lewis wrote:

>P. T. Withington wrote:
>> 
>> On 3/31/98 23:41, Chris Hanson wrote:
>> 
>> >At 10:05 PM -0600 3/31/98, Chris Bitmead wrote:
>> >>The MIT lisp code would surely be interesting, but I really doubt
>> >>it is going to be much more than a curiousity rather than the
>> >>base for a new LispOS.
>> >
>> >That all depends how hard it would be to write an emulator for the hardware
>> >it ran on... :)
>> 
>> Can't be much harder than JVM.  That's what Symbolics did to make "Open
>> Genera" -- it is a LispM emulator that runs on Alphas.  On a top of the
>> line Alpha, it runs many times faster than the custom hardware ever did.
>> (Another way of thinking about it:  the Alpha chip is the micro engine
>> and the emulator is the microcode.  One reason the emulator runs so fast
>> on the Alpha is that we were very careful to fit the "microcode" and
>> "engine" into the Alpha's on-chip instruction and data caches.)
>> 
>> OTOH, the portable C prototype of the emulator ran like a dog...
>
>OTOH, once we had a (that??? Ah, that'd be fun!) portable C
>implementation, there are a lot of tricks to optomize it that probably
>weren't done to that prototype. Instead they went to optimize Alpha
>assembler instead. Now, if we were to take that C and use it to generate
>a baseline VM and then translate the VM code into Lisp, we could use the
>initial VM to bootstrap a better VM. A similar technique is used in
>Squeak. There is an excellent paper by the Squeak implementation team
>describing this on my web page. It's a zipped word 95 file.

Well there were several Lisp emulators written:  one to emulate the chip 
at the gate level and one that emulated the chip at the instruction 
level, both used to debug ported software before the chip was ready.  The 
C and assembly were both inspired by the instruction emulator.  The big 
hit on performance was emulating a 40-bit word on a 32-bit machine.  
Alpha makes that easier, being a 64-bit machine.  And only the core 
execution engine was in assembly, there was lots of supporting C code -- 
the VM implementation for instance, was written mostly in C.  The 
tightest assembley was required for memory read/write which on the Lisp 
hardware does tag checking, invisible pointer following, and gc barriers. 
 In the end, a LispM read took 7 Alpha cycles.