aglew@mcdurb.Urbana.Gould.COM (06/01/89)
>/* May 23, 1989 by bcase@cup.portal.com in mcdurb:comp.arch */ >Well, the jury has given its verdict: I was wrong in complaining about >John Mashey's long, marketing-oriented posting. Since this court's >decision applies to all citizens, I now have the same freedom to post >stupid stuff (i.e., the same stuff I have always been posting!). I know I'm going to get flamed for this, but... Brian, please don't start getting involved in counter-measures. Mash, I know it's not up for votes, but some of your posts recently have been long on marketing and short on the detailed technical data that we have grown to value your posts for. Actually, I would describe them as "pseudo-technical" discussions. I had a technically oriented boss who would drown out argument by using the same technique, of piling on the detail, of talking about all the tradeoffs, until you didn't notice the slant he was taking. Nonetheless, Mash's posts are still interesting, even though tiresome, and I am enjoying the back-and-forth of theories of marketing. It's just getting close to my limit. How about the participants in the marketing wars taking a deep breath, trying to do only short posts for a while -- and then starting up on their diatribes next month with a fresh and interesting set of arguments, instead of going over all the old ones again and again?
aglew@mcdurb.Urbana.Gould.COM (06/01/89)
>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.