Make LispM code FREE (fwd)

[P. T. Withington]

On 4/1/98 16:45, William A. Barnett-Lewis wrote:

>P. T. Withington wrote:
>> 
>> 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:
>(CHOMP)
>
>> 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.
>
>Ah. The word size differences; that makes somewhat more sense. Would
>this allevied by the P2 and PPC being 64 bit internally? They would
>still be choked by the bus width, but it shouldn't be as big a hit as
>emulating 40 bits in 32. 

Possibly, but the 64-bit address space was important too.

>Perhaps it would be best, overall, to make the jump to a full 64 bit
>implementation...     !

In the "Virtual Lisp Machine", as we called it, we took advantage of the 
64-bit address space two ways:  The LispM address space was modelled as 
two 2^32 arrays:  a 32-bit array for data and an 8-bit array for tags.  
With this arrangement we could almost get parallel data fetch and tag 
check, like the real hardware.  On a 32-bit machine, the address space 
has to be modelled as a sparse array making load and store quite 
expensive.

In the core micro-engine the stack cache was emulated using a 64-bit 
array with the tag in the high 32-bits and the data in the low 32-bits.  
The stack cache was sized to share the on-chip data cache with the 
micro-engine's instruction cache (which looked like data to the alpha 
chip).  Using combined tag and data for the stack cache meant push, pop, 
etc. were single alpha instructions when their operands were in the cache.