Make LispM code FREE (fwd)

[William A. Barnett-Lewis]

Hmm, so would the address space -loss- be too significant if one used a
24 bit array for the data and an 8 bit array for the tags? It would seem
to me to be an acceptable compromise, since then it would fit into a 32
bit word. IIRC, the LMI K-machine was designed using that compromise.

Of course this still wouldn't help the cache design you describe...

It seems to me that as things currently stand in the affordable PC
realm, ie PPC Macs and x86 PCs, that trading ultimate address size for
acceptable performance would be the Gabriel (AKA "Worse is better")thing
to do. With proper coding, the 32 bit arrays could be increased when 64
bit systems - both internal and external to the CPU - are available.

OTOH, I'm an utter amateur at these issues and may be missing something
significant...

William

P. T. Withington wrote:
> 
> 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.

-- 
_______________________________________________

Live without fear; your Creator loves you
as a mother. Go in peace to follow the good
road and may God's blessing be with you always.
St. Claire
_______________________________________________