[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Risc vs Symbolics (was: Poor Sun timings, as competition...)
- To: IEXIST!att!ai.sri.com!slug@Warbucks.AI.SRI.COM
- Subject: Risc vs Symbolics (was: Poor Sun timings, as competition...)
- From: lgm@iexist.att.com
- Date: Mon, 13 Aug 1990 20:08:00 -0400
- In-reply-to: <9008130803.AA04804@libeccio.tecsiel>
- Original-from: Larry Mayka <iexist!lgm>
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.
I suppose it should be possible, isn't it ? (don't care the
development costs, it is just an hypothesis).
How the result would compare to the original Genera on a Symbolics?
(Be fair: consider enough amount of core memory, and machine of the
same generation; consider a UNIX workstation or a bare workstation as
you need it).
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.
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.
Lawrence G. Mayka
AT&T Bell Laboratories
lgm@iexist.att.com
Standard disclaimer.