Xref: utzoo comp.arch:11216 comp.sys.mips:136
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!ames!amdahl!pyramid!prls!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch,comp.sys.mips
Subject: Re: Memory utilization & inter-process contention
Message-ID: <26595@winchester.mips.COM>
Date: 31 Aug 89 16:35:12 GMT
References: <70663@yale-celray.yale.UUCP> <1989Aug26.232710.27174@utzoo.uucp> <1989Aug30.152155.9613@mentor.com>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 48

In article <1989Aug30.152155.9613@mentor.com> plogan@mentor.com (Patrick Logan) writes:
>In article <1989Aug26.232710.27174@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>Take a look at the history of Lisp on Lisp machines, whose time has come
>>*and gone* -- those awful "C-only" RISC machines run Lisp faster than the
>>custom-cooked Lisp machines do.

>Saying that C machines run Lisp faster than Lisp machines is
>simplistic. To run Lisp faster on a C machine requires more
>declarations in the code (or, as with T, more use of "type-specific"
>procedures such as fx+ instead of generic +). This goes against the
>grain of Lisp programming.
>
>Lisp machines provide a better environment (e.g. protection, ability
>to write fast, generic code) per performance unit. I'd guess the only
>reasons their time is gone are market based. They're sure to return in
>one form or another as more and more C machine programs are written in
>Lisp-like languages. Many C machine architectures (e.g. SPARC) already
>incorporate some support for Lisp.

There are many good ideas in LISP, and more of it will filter over.
The issue (and it has been discussed before in comp.arch), is that
the economics of the computer business end up with the following:
	a) If something is a low-volume, special-purpose architecture,
	it must be MUCH better at what it does than the high-volume,
	cheap competition.  If it isn't, it will end up going away,
	because the competition gets to keep tracking the technology
	curve at speed, rather than getting behind it.  also,
	if something has high-volume in VLSI, it gets to be cheap.
	b) The current RISC chips are getting fast and cheap enough
	that this is happening.
	c) There is still some fine-tuning to be done, but most of
	them are more like tweaks added to some of the existing
	architectures (tagged adds, for example, by themselves, do
	not necesarily solve the problem: consider the exception-
	handling sequences also needed).

Useful datapoints might be, now and in future:
	a) Symbolics, Inc. history, where it seems like they're
	geting out of hardware-design business in favor of (fine) software.
	b) TI: Ivory chip versus SPARCs

CONJECTURE/PREDICTION: fast VLSI RISCs will end up capturing the high
end of the LISP market over the next few years.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086