🚀 go-pugleaf

In article <674@pitstop.West.Sun.COM> jwest@pitstop.West.Sun.COM (Jeremy West) writes:
>
>
>A large number of comp.arch readers are interested in embedded
>realtime and a large number of SPARC designs are  in this category.
>For them an integer unit is all you need. I take the points about
>availability of full chipsets at hign clock rates.

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.

Having said that, the same is pretty much true for MIPS.  This is not
a reflection on the quality of their architectures for the workstation
world.  It is a statement about their (current) *implementations* in the
embedded world.

I suspect that Sun is beginning to attempt to position SPARC in
realtime and embedded markets: a) as a fallback position in case they
don't succeed as thoroughly as they hope in the workstation market; and
b) because the volume of design wins and chip sales in 32-bit embedded
control is (conservatively) 10x the workstation market.

This is the same strategy that drove AMD to move the 29k out of
workstation land, as well as Weitek and the XL8xxx, and (of late)
National and the 32k series.

S. McGeady
Intel Corp.