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

["David L. Andre" <DLA@jasper.scrc.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?

The 3600 family has a 28 bit virtual address space and a 24 bit physical
address space.  Ivory has a 32 bit virtual address space and a 32 bit
physical address space.

    While I'm asking questions:

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

Slowly.  That's one of the reasons why an XL400 is more than twice the
speed of a MacIvory.

    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.
    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.  Is the memory potentially bad enough
    to require a lot of error-fixing overhead?

Lisp systems do not tollerate any memory failures; when one is detected
the entire system halts, usually with an obscure GC or paging error.

The implementation cost and risk for ECC is not high, since the Ivory
processor handles ECC on chip, in parallel with instruction execution.

    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?

Questions like this are best answered by the Genera 7.3 Ivory
documentation:

       1General Considerations

0       2A key aspect of Genera's design philosophy is that different3 2architec-
0       2tural levels are carefully separated, and may be changed3 2indepen-
0       2dently.3 2The instruction set architecture may be changed, as it3 2was
0       2when the 3600 series was introduced, without affecting the overall
0       2system architecture.3 2The processor architecture may be freely
0       2changed,3 2as it was in the 3675, 3620, and 3650, with no effect on the
0       2software.3 2Or, the overall system architecture may be changed, as it
0       2was in Genera3 27.0, independent of the underlying instruction set and
0       2processor3 2architecture.

0       2Ivory-based systems use a different instruction set and processor3 2ar-
0       2chitecture than the 3600 series, but maintain the Genera 7.0 system
0       2architecture and provide full source-code compatibility for Genera
0       2applications.3 2The new architecture enables a single-chip processor
0       2implementation, with accompanying benefits in system cost, perfor-
0       2mance,3 2reliability, and the opportunity to configure systems that were
0       2previously infeasible.

0       2Source code compatibility means that programs using Common Lisp,
0       2Symbolics Common Lisp extensions, or the Genera substrate in the
0       2documented manner need only be recompiled in order to run on the
0       2new3 2machines.3 2Symbolics' layered languages, and the code they pro-
0       2duce, are3 2compatible to this same degree.3 2Object code produced for a
0       23600-series3 2machine (in binary files or world loads) may not be load-
0       2ed into an3 2Ivory-based machine, or vice versa.

0       2Therefore, the porting task primarily consists of recompiling software,
0       2and maintaining and distributing consistent object code for both3 2fami-
0       2lies of machines.3 2Occasionally, an application will require source
0       2changes to make it portable to the Ivory-based series; this can3 2result
0       2from the use of undocumented internal functions of the system, or
0       2more rarely from the use of low-level `subprimitive' operations, as
0       2discussed in the section Changes to Subprimitives and System Con-
0       2stants for Genera 7.3 Ivory.

0       2Once an application is ported to Genera 7.3 Ivory and the Ivory pro-
0       2cessor,3 2you might want to change its user interface, for instance to fit
0       2into the3 2Macintosh user interface in a MacIvory system.3 2This is best
0       2done after3 2the basic porting is done.3 2You might also want to tune the
0       2application's performance, (see the section "Metering Interface").

0       2In addition, you may also want to use the new scheduler. For further
0       2information: See the section "Converting to the New Scheduler for
0       2Genera 7.3 Ivory".3