[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Risc vs Symbolics (was: Poor Sun timings, as competition...)
- To: iexist!att!fuji.ila.com!rwk@Warbucks.AI.SRI.COM
- Subject: Risc vs Symbolics (was: Poor Sun timings, as competition...)
- From: email@example.com
- Date: Wed, 15 Aug 1990 22:55:00 -0400
- Cc: IEXIST!att!ai.sri.com!slug@Warbucks.AI.SRI.COM
- In-reply-to: <19900814082611.8.RWK@KILIMANJARO.ILA.COM>
- Original-from: Larry Mayka <iexist!lgm>
Date: Tue, 14 Aug 90 04:26 EDT
From: Robert W. Kerns <RWK@fuji.ila.com>
Date: Mon, 13 Aug 90 19:08 CDT
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
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