Xref: utzoo comp.misc:2414 comp.arch:4863
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.misc,comp.arch
Subject: Re: Japanese 32-bit micro can be a 68020 or 80386
Message-ID: <53583@sun.uucp>
Date: 17 May 88 20:14:10 GMT
References: <2006@sugar.UUCP>
Sender: news@sun.uucp
Lines: 44

> Even the immediate implications are stunning, I think.  One thing is that 
> those of us who have always wanted to diddle microcode may soon be able to, 
> tho' there won't be much software or software compatibility for those who
> do (the Microprogramming Construction Set?).  It would be a boon to
> researchers and others trying to implement oddball language architectures
> and get them to execute efficiently on a CISC-type machine (Smalltalk, LISP, 
> etc.)

Well, maybe.  An earlier article in "comp.arch" claimed:

> From: mdr@reed.UUCP (Mike Rutenberg)
> Newsgroups: comp.arch,comp.lang.smalltalk
> Subject: Re: hardware for late-binding languages
> Keywords: Smalltalk
> Date: 17 May 88 05:37:19 GMT
> Organization: Reed College, Portland OR

> The tendency among Smalltalk implementations (a very late bound language)
> is to run on standard CPUs like 68020s or 80386s.

> You might propose that a custom instruction set or hardware support
> would make the implementation faster.  Specific hardware support may
> help a given implementation, but you then have to build the next
> generation of that machine if the performance win is going to continue
> with you.

> If you do your own custom hardware to support a language, you have to
> do it all, both the software and the hardware.  You can't spend as much
> time building fast software and you don't get the automatic win
> that occurs when somebody *else* spends the millions to do something
> like an mc88000.

> It looks to me that you get the fastest language machines by concentrating
> on building fast software that will work on the fastest standard CPUs.

I'm not sure that the "buckets of microcode" or, if you will, the "use the
microcode as a fast machine language and write a big interpreter in this
machine language" approach is necessarily the only way to get those languages
to run efficiently, or even necessarily the best way.

> Imagine a version of the microprogrammable chip in which the operating
> system could context switch among trusted sets of microprograms.  Weird.

Weird, maybe, but did not the Burroughs 1700 series do this a long time ago?