Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jato!vsnyder
From: vsnyder@jato.jpl.nasa.gov (Van Snyder)
Newsgroups: comp.sys.atari.st
Subject: Re: RISC business
Message-ID: <1991Apr18.182153.14662@jato.jpl.nasa.gov>
Date: 18 Apr 91 18:21:53 GMT
References: <12536@uhccux.uhcc.Hawaii.Edu>
Reply-To: vsnyder@jato.Jpl.Nasa.Gov (Van Snyder)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 48

In article <12536@uhccux.uhcc.Hawaii.Edu> kiki@uhunix2.uhcc.Hawaii.Edu (Jack W. Wine) writes:
>
>+vsnyder@jato.jpl.nasa.gov (Van Snyder) writes:
>
>+From an article in April Datamation, I see that Sparc International is only
>+half-open: Their "shrink-wrap" API requires Sun-OS.  The article was about
>+the 88000.  88Open doesn't require a certain OS to be compliant...
>
>SunOS can be licensed from either Sun or Interactive Systems.  Wouldn't 
>a stringent OS compliance policy for the 88Open be better for developers
>and users, in the long run?

88Open requires just as stringent compliance as Sparc International.  The
difference is that 88Open depends on the _external_ behaviour of the OS,
while Sparc International depends on the _internal_ behaviour of the OS.
Even in 1972, Parnas told us this was _bad_ software engineering.

>+The article praised the 88000 and 88Open on technical grounds, but mentioned
>+that Motorola's marketing was "methodical at best."  It also mentioned that
>+Motorola has cut the 88000 price by 2/3, and that the 88010 will be out "soon"
>+Top-of-the-line 88000 is about as fast for non-floating-point as the fastest
>+Sparc or MIPS, but has better support for multiprocessor architectures
>+(according to Harris, who build a multiprocessor server from it)....
>
>I won't argue about the technical superiority of the 88000, but the first ques-
>tion I would have is whether Motorola would allow it to be second-sourced...

Probably not.  Motorola has good engineers.  That's all.

>It wasn't because of their (past) marketing strength, that I thought a PgC-
>based system from Atari was plausible.  Their development (in conjunction
>with Perihelion Hardware and Software) of the ATW, resulted in a system with
>awesome capabilities.  Unfortunately, it was based on chips from a manufacturer
>who was financially unstable and incapable of producing the chips in volume...

It's my understanding that part of Inmos' problem was in getting screwed by
US DoD:  They set up a factory in Colorado Springs, from which Atari hoped
to get Transputers.  Then US DoD wouldn't let Inmos re-export Transputers
to UK!.  Not wanting to keep two Transputer production lines going, Inmos
shut down the Colorado Springs operation, and got hurt in the overall deal.

>Jack


-- 
vsnyder@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsnyder@jato.uucp