🚀 go-pugleaf

>In this late response I wish to avoid the protracted debate (name-calling?)
>currently happening between SPARC and MIPS advocates.  Let me say simply
>that, as a contended in the embedded processor market (with the Intel 960),
>I do not believe that many people are taking SPARC seriously as an embedded
>controller.  The chips require too much board space and support logic, they
>require a cache (almost always out of the question for embedded designs),
>have unpleasant code expansion characteristics, are too expensive, and have
>too little development support (e.g. no In-Circuit Emulators) for most
>embedded applications.

Re: caches (almost always out of the question for embedded designs)

There are lots of definitions of real-time, and lots of definitions of
embedded.  At Gould I worked on CMOS and ECL multi-board computers that
were "real-time", used in the real-time simulation market, and were 
"embedded" in systems.  These guys had fairly tight timing constraints,
worried in detail about worst case times, etc. I thought that this was 
soft real-time, and that "hard" real-time had even tighter timing 
constraints -- but at my new company I have heard of the "real" real-time
market, in avionics, etc., that just wants raw speed, not necessarily
determinism.  Eg. they want to process as many threats as possible
(or check as many aircraft as possible for collision course, in a more
peaceful application)  and are willing to trade off determinism for thruput.
And these are embedded in the sense of being placed in an aircraft's nose...

All of this verbiage was just to say:  caches are not always out of the
question for "embedded" or "real-time" designs. As always, it depends
on the application requirements.