Risc vs Symbolics (was: Poor Sun timings, as competition...)

[SWM@SAPSUCKER.SCRC.Symbolics.COM (Scott McKay)]

    Date: Mon, 13 Aug 90 19:08 CDT
    From: lgm@iexist.att.com

	Date: Mon, 13 Aug 90 10:03:56 +0200
	From: mdc%libeccio.TECSIEL.IT@CUNYVM.CUNY.EDU

	Suppose to write a RISC (for example SPARC) code generator for the
	Symbolics Compiler (and to write all the needed hardware specific
	run-time), and then to compile the *WHOLE* Genera on a RISC
	Workstation.

	How the result would compare to the original Genera on a Symbolics?

    Porting of Genera to a conventional processor is one part of what I'd
    like to see: a Genera suitable for a real-time embedded system.
    Ideally, this would mean:

    1) An inexpensive, mass-produced processor.  I don't see how an Ivory
    can match the economies of scale of a SPARC or MIPS in the long run
    (without a major change in industry direction), so one alternative is to
    port Genera to another processor, at least eventually.

    2) Real-time responsiveness from the operating system.  I would need a
    slimmed-down version of Genera, one small enough to fit entirely in RAM,
    since paging from disk is unacceptable for my purposes.  For this reason
    a port of Genera to the UNIX System is of only secondary interest to me.

It doesn't sound to me like you want a slimmed-down version of Genera,
what you want is a way to include in an application image exactly what
that application needs in order to work at run time, and nothing more.
In general, this is not easy; the most obvious loophole is EVAL,
although even INTERN can be problematic.  Furthermore, the compiler can
be invoked at run time in order to compile CLOS effective methods,
although there are obviously ways to avoid this.

    3) Continuous alert operation for extremely long periods of time.  This
    requires incremental garbage collection of all memory, including
    compiled functions etc.  Of course, I don't think an unmodified SPARC or
    MIPS can do this very easily today.  At one time Texas Instruments was
    expressing interest in adding functionality to the SPARC design to run
    Lisp better; perhaps, if they ever do this, they'll include support for
    incremental garbage collection.

I don't see how the requirements for true "real time" and "incremental
garbage collection of all memory, including compiled functions" can
possibly co-exist.  By its very nature, GCing is the enemy of "real
time".