Xref: utzoo comp.misc:2422 comp.arch:4869
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.misc,comp.arch
Subject: Re: Japanese 32-bit micro can be a 68020 or 80386
Message-ID: <401@m3.mfci.UUCP>
Date: 18 May 88 13:00:52 GMT
References: <2006@sugar.UUCP> <53583@sun.uucp>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 63

In article <53583@sun.uucp= guy@gorodish.Sun.COM (Guy Harris) writes:
== 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)
== 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?

Some of you guys may also remember the Perq, from Three Rivers
Computer/Perq Systems.  It had a user-writable microstore in a
roll-your-own bit-slice CPU, and I think one of the reasons for its
demise was what Mike mentioned above -- it's really hard to compete
with the microprocessor guys on performance (and that's ignoring the
price difference).  At any given micro incarnation, one can probably
construct something out of existing less-dense technology and beat
it, but it's a hard game to play.  And if you're also having to come
up with new OS revisions, new compilers, and also maintain your
benchmarking and marketing, it's even tougher.  A Perq was capable of
very high performance when judiciously microcoded, but that didn't
sell enough of them to make up for all the disadvantages of
proprietary hardware and compilers.

One other thing.  The micros I worked on had "nanocode", a la the 68K
series, and if somebody had handed us a large enough pot of money, I
suspect that we'd have been able to let them do another version of
the chip with their own custom microcode.  But the performance would
not have been that much higher -- at the nanocode level of a
microprocessor, there are very significant constraints on what is
possible (chip bus contention, vertical microcode decoding, state
machine restrictions).  Unless you designed your micro for an unusual
degree of orthogonality *at the functional-unit level*, you may be
pretty disappointed at what hand-microcoding at that level could buy
you.  And if you DID design it that way, I'd bet that your basic
performance is going to suffer substantially as compared to your
counterpart designing the 68XXX.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090