Re: [Spock@SAMSON.cadr.dialnet.symbolics.com: IFU]

[Doug Evans <DE@phoenix.sch.symbolics.com>]

    Date: Fri, 2 Dec 88 12:32 CST
    From: gadbois@sygmund.cgs.utexas.edu (David Gadbois)

	Date: Fri, 2 Dec 88 08:46 PST
	From: DE@PHOENIX.SCH.Symbolics.COM (Doug Evans)

	[ stuff deleted ]

	Also, it's pretty difficult to squeeze performance out of a 40bit
	computer with a 32bit address space when it has to use a bus structure
	with 36bit datapaths and 24bit addresspaths.
				 ^^

    I thought the address path was 28 bits, since the word organization is
    (I'm told) 28-bit address + 6-bit tag + 2-bit cdr code or 32-bit
    immediate data + 2-bit tag + 2-bit cdr code.  If the address path is
    24-bit, how do you deal with the extra 4 bits?

In the Lisp Machine L-Bus, addresses and data do not share the same bus.

The actual width of the machine word is 36bits; for instruction words
there is a 2bit cdr code and and two 17bit instructions; for most data
words there is a 2bit cdr code, a 2 bit tag code and 4 bytes of data.
(There are other kinds of data words with more tag bits.)

The actual width of the address bus for physical addresses is 24bits.  A
27bit virtual address word is used by the processor, but is translated
by the memory controller into the 24bit physical address.

    While I'm asking questions:

    How does the MacIvory do 40-bit (or 48 -- see next question) words with
    the 32 bit NuBus?

Thru a packing scheme that, in some cases, might cause a performance
penalty ... except that there is a cache memory on the MacIvory
processor board ... the following copied from a MacIvory description: 

----------------------------------------------------------------------

48-bit operations that require memory access (all memory writes,
uncacheable reads, cacheable read misses) perform a 32-bit  48-bit
conversion which works as follows.  One or more region(s) of host memory
are set aside to serve as the backing store for Ivory's 48-bit accesses.
The regions are broken into blocks of 6 32-bit words where each block
holds the contents of 4 48-bit Ivory words.  For example, Ivory
locations 0 through 3 appear to the MAC II host as

	MSB				  LSB
	+-----------------------------------+
	| ECC<1> | TAG<1> | ECC<0> | TAG<0> |   BASE
	+-----------------------------------+
	| ECC<3> | TAG<3> | ECC<2> | TAG<2> |   BASE + 4
	+-----------------------------------+
	|              DATA<0>              |   BASE + 8
	+-----------------------------------+
	|              DATA<2>              |   BASE + 12
	+-----------------------------------+
	|              DATA<1>              |   BASE + 16
	+-----------------------------------+
	|              DATA<3>              |   BASE + 20
	+-----------------------------------+

----------------------------------------------------------------------

    I may be confused by this, but the literature I've read implies about
    the XL400 says it's memory organization includes 8 bits of error
    correction/detection, and that its Ivory board handles the ECD itself.

Sorry, I was ignoring ECC bits. LMachines have seven bits of ECC plus a
spare bit (for what who knows ... it was never used) for a total data
bus width of 44bits.  IMachines (ala XL400 or only on the MacIvory
Processor card) use 8bits of ECC for a total databus width of 48bits or
6 bytes.  

    Is the MacIvory set up that way too?  Since this is a substantial amount
    of memory overhead (and maybe silicon, too), I was wondering what the
    design argument was to add it in.

ECD and ECC is handled internally in the Ivory chip, not requiring
external logic on the processor board.
					Is the memory potentially bad enough
    to require a lot of error-fixing overhead?

I doubt it, but you still can't completely trust dynamic rams.

    I think that the 3600 architecture allowed for up to 34 tags.  The
    Ivory, with a full 6-bit tag field (assuming you're still using 2 bits
    out of the 40 for a cdr code), lets you have up to 64.  Aren't there
    some big incompatibility potentials here?

Maybe, but not as much as you might think.  Memories in Lispms are very
stupid, having an absolute minimum of logic needed to support high-speed
reads and writes.  The processor takes care of bundling and unbundling
of all fields.  So what fields might exist in a data word are not
important outside of the processor out on the bus and peripheral cards.

That is even more true in MacIvory, where (hopefully?) any NuBus memory
that can work on a Mac will work for the MacIvory.  We can't depend on
custom organization or support logic existing on such memories.