martin@minster.york.ac.uk (05/25/90)
In article <1990May22.072208.15547@city.ac.uk> sb380@city.ac.uk (HOLT A D) writes: >In article <j5dps8023@tmsoft.uucp> mason@tmsoft.UUCP (Dave Mason) writes: >> ..... >>>It wasn't for want of trying; a lot of people lost their shirts on it. >>>The successful ones can be counted on your thumbs. >> >>(That's how you do it Henry, you have extra hands :-) I count at least >>Encore, Sequent, Whitechapel,... in the Unix market. 32000s are also >>very popular in Laserprinters) >> >But Whitechapel went bust .... >(and Sequent changed to the Intel chip - don't know about Encore) Yes, and the machines that Whitechapel were working on, when they went bust, were based on the MIPS R3000!!! > >Andy > >who needs a signature anyhow? Indeed!
stevew@wyse.wyse.com (Steve Wilson xttemp dept303) (05/31/90)
In article <JIM.90May22114540@baird.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: >Sequent went >for the NS32032 (as opposed to an M68k) because it didn't have an >on-chip cache which would have made a shared-memory multiprocessor box >difficult to build. At that time (6-7 years ago), First question is how does an on-chip cache help with a shared-memory multiprocessor box? It should make things more difficult due to cache coherency issues. Also note that the 32032 didn't have an on-chip cache either. Perhaps you mean the MMU(32032 didn't have on-chip MMU, but did have a simi-working MMU chip.) Steve Wilson
rogerk@mips.COM (Roger B.A. Klorese) (05/31/90)
In article <2732@wyse.wyse.com> stevew@wyse.UUCP (Steve Wilson xttemp dept303) writes: >In article <JIM.90May22114540@baird.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: >>Sequent went >>for the NS32032 (as opposed to an M68k) because it didn't have an >>on-chip cache which would have made a shared-memory multiprocessor box >>difficult to build. At that time (6-7 years ago), > >First question is how does an on-chip cache help with a shared-memory >multiprocessor box? It should make things more difficult due to >cache coherency issues. Also note that the 32032 didn't have >an on-chip cache either. Perhaps you mean the MMU(32032 didn't >have on-chip MMU, but did have a simi-working MMU chip.) You're right, and so's Jim; you just parsed his statement incorrectly. He said that Sequent went for the NS32032, as opposed to an M68K, because the NS part didn't have an on-chip cache, and on-chip caches would have made a shared-memory multiprocessor box like Sequent's difficult to build. -- ROGER B.A. KLORESE MIPS Computer Systems, Inc. phone: +1 408 720-2939 MS 4-02 950 DeGuigne Dr. Sunnyvale, CA 94086 voicemail: +1 408 524-7421 rogerk@mips.COM {ames,decwrl,pyramid}!mips!rogerk "I'm the NLA" "Maybe this world is another planet's hell." -- Aldous Huxley
stevew@wyse.wyse.com (Steve Wilson xttemp dept303) (05/31/90)
In article <2732@wyse.wyse.com> stevew@wyse.UUCP (Steve Wilson xttemp dept303) writes: >In article <JIM.90May22114540@baird.cs.strath.ac.uk> jim@cs.strath.ac.uk (Jim Reid) writes: >>Sequent went >>for the NS32032 (as opposed to an M68k) because it didn't have an >>on-chip cache which would have made a shared-memory multiprocessor box >>difficult to build. At that time (6-7 years ago), > >First question is how does an on-chip cache help with a shared-memory >multiprocessor box? It should make things more difficult due to >cache coherency issues. Also note that the 32032 didn't have >an on-chip cache either. Perhaps you mean the MMU(32032 didn't >have on-chip MMU, but did have a simi-working MMU chip.) > >Steve Wilson As has been pointed out to me rather politely (as oppossed to the flame it probably deserved) I mis-read the original comment. Sorry about that folks.... Maybe the only useful item in the posting was that the MMU available from NSC at the time perhaps played a role in Sequent's decision. I know the MMU was an important factor for Tolerant System choosing the 32K. Steve Wilson