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

[RWK@fuji.ila.com (Robert W. Kerns)]

    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.

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

    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.

Actually, that's an over-simplification, but the point is that
real-time response does *NOT* require elimination of parts of
the system.  (On the other hand, the use of very small disks, or
ROM, etc. *DOES* require such steps).

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