home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / intel / 1603 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.6 KB  |  54 lines
  1. Newsgroups: comp.sys.intel
  2. Path: sparky!uunet!caen!sdd.hp.com!megatek!rstewart
  3. From: rstewart@ganglia.megatek.uucp (Rich Stewart)
  4. Subject: Re: Future of i860 line
  5. Message-ID: <1992Aug28.182116.4396@megatek.com>
  6. Sender: rstewart@megatek.com (Rich Stewart)
  7. Reply-To: megatek!rstewart@uunet.uu.net
  8. Organization: Megatek Corporation, San Diego, California
  9. References: <BtLGIG.3q2@pgroup.com> <TMH.92Aug26230950@doppel.first.gmd.de> <1992Aug28.162446.20124@crd.ge.com>
  10. Date: Fri, 28 Aug 1992 18:21:16 GMT
  11. Lines: 41
  12.  
  13.  
  14. >In article <TMH.92Aug26230950@doppel.first.gmd.de> tmh@doppel.first.gmd.de (Thomas Hoberg) writes:
  15. >>In article <BtLGIG.3q2@pgroup.com> I write:
  16. >>   Actually, the announcement was that Intel had admitted the failure of
  17. >>   the i860 as a general-purpose CPU.  They still intend to support it in
  18. >>   graphics and embedded applications; speculation is that they will also
  19. >>   support it for the iPSC MPP systems.  No followon has been announced,
  20. >>   but one would obviously be needed if they do indeed plan to continue to
  21. >>   use i860-like chips in the iPSC.
  22. >>
  23. >>Why did it fail, though? While there might be better CPUs today, I
  24. >>thought it pretty good when it came out. Was there anything seriously
  25. >>wrong with it (except that it'd do virtual caching)? Was it just that
  26. >>the various vendors were too busy promoting their own designs or
  27. >>tuning their old architectures? Is it just bad luck that nobody
  28. >>decided to pick it up or is there something about the i860 that I
  29. >>missed?
  30. >
  31.  
  32. My guess is that it is not a superscalar design. The chip relies heavily
  33. of the code generating all the pipe lining. This makes  compiler
  34. writing difficult (right Larry?). It makes assembly coding difficult.
  35. It leads to slower nominal performance rates. While an i860 is very fast
  36. on an infinitely long vector:vector operation (100 mflop @ 50 M) for 
  37. floating point that doesn't vectorize, it is less than blazing. 
  38.  
  39. Superscalar designs also handle concurrent execution of different processing
  40. units alot nicer. 
  41.  
  42. So, if INTEL took an i960 core, expanded it to 64 bits wide, mix in floating
  43. point, of i860 speeds, with out that damned pipelining by hand stuff, 
  44. had some SHARED registers between the floating point
  45. and integer sections, did speculative instruction execution on the alu and
  46. fpu, provided a 64 bit alu which ops could be segmented into 
  47. 2*32, 4*16, or 8*8 bit concurrent 2's compliment operations, AND ALLOWED THE
  48. ENTIRE DATA CACHE TO BE BOOT TIME SELECTABLE AS EITHER DATA CACHE OR MEMORY
  49. MAPPED FAST DATA STORAGE, I'd be happy, and I think it would sell, IMHO. 
  50.  
  51. -Rich
  52.  
  53. rstewart@megatek.com
  54.