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

[lgm@iexist.att.com]

    Date: Tue, 14 Aug 90 10:10 EDT
    From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>

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

	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.

I'm willing to spend the RAM necessary to hold the full Common Lisp
definition, and probably even the compiler.  But a lot else in Genera
(e.g., windowing) is unnecessary for my purposes, and presumably is
responsible for Genera's large virtual image size.

	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".

My application has a "soft" real-time requirement, such that GC is
acceptable as long as it never hogs the processor for more than, say, 20
milliseconds at a time.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.