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

[lgm@iexist.att.com]

    Date: Tue, 14 Aug 90 04:26 EDT
    From: Robert W. Kerns <RWK@fuji.ila.com>

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

	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.

    Actually, I see the iron that runs the software to
    be an ever-shrinking portion of the total cost.  I've
    spent many times the $$$ on software for my mac than I
    have for hardware, and I have a quite hefty configuration.

The counter-argument is that custom software's per-copy cost can become
small at production levels at which custom hardware is still relatively
expensive.

    Anyway, that's Symbolics' real problem; the software
    makes the iron look too expensive.  Actually, the real
    problem is that Symbolics' management historically
    hasn't understood this problem at all, and persisted
    in trying to be a primarily hardware company, with ever-
    shrinking hardware prices being called on to support
    ever larger software efforts.  (And administration and
    idle real-estate and...)

You bring up an interesting question:  Just what is the hardware cost of
an Ivory processor board?  Or, hypothetically:  Could Symbolics supply
embedded Ivory systems to an OEM at a price in the same ballpark with
SPARC- or MIPS-based systems?

	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.

    You can do this yourself pretty easily.  Just lock down the relevant
    code and structures.  Just because ZMail is in your virtual address
    space doesn't mean it has to be in RAM.

Such locking-down would have to comprehensively include everything the
real-time code touches, including consed-up lists, interned symbols,
saved print-names, etc.  Is it possible to ensure that a particular
process does all its consing from a particular area?  Similarly, garbage
collection would have to limit itself to the locked-down area so as not
to provoke paging.  (Unless important work could continue during the
paging.  It can on a timeshared system; can it do so on the Symbolics?)

	3) Continuous alert operation for extremely long periods of time.  This
	requires incremental garbage collection of all memory, including
	compiled functions etc.  

    Why?  This is only needed if you're dynamically creating
    compiled function objects and then discarding them.  Most
    "continuous alert" applications aren't likely to do that;
    it's sort of incompatible with their mission to invoke
    the compiler a lot...

An application that must run continuously for very long periods of time
must be able to accept on-the-fly program and data structure updates
while still maintaining its real-time responsiveness.


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

Standard disclaimer.