home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / intel / 1604 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.3 KB  |  55 lines
  1. Newsgroups: comp.sys.intel
  2. Path: sparky!uunet!pgroup!lfm
  3. From: lfm@pgroup.com (Larry Meadows)
  4. Subject: Re: Future of i860 line
  5. Message-ID: <BtpMqA.CzB@pgroup.com>
  6. Date: Fri, 28 Aug 1992 20:10:57 GMT
  7. References: <TMH.92Aug26230950@doppel.first.gmd.de> <1992Aug28.162446.20124@crd.ge.com> <1992Aug28.182116.4396@megatek.com>
  8. Organization: The Portland Group, Portland, OR
  9. Lines: 44
  10.  
  11. In article <1992Aug28.182116.4396@megatek.com> megatek!rstewart@uunet.uu.net writes:
  12. > [ discussion about why the i860 failed deleted ]
  13. >
  14. >My guess is that it is not a superscalar design. The chip relies heavily
  15. >of the code generating all the pipe lining. This makes  compiler
  16. >writing difficult (right Larry?). It makes assembly coding difficult.
  17.  
  18. Right.
  19.  
  20. >It leads to slower nominal performance rates. While an i860 is very fast
  21. >on an infinitely long vector:vector operation (100 mflop @ 50 M) for 
  22. >floating point that doesn't vectorize, it is less than blazing. 
  23. >
  24. >Superscalar designs also handle concurrent execution of different processing
  25. >units alot nicer. 
  26. >
  27. >So, if INTEL took an i960 core, expanded it to 64 bits wide, mix in floating
  28. >point, of i860 speeds, with out that damned pipelining by hand stuff, 
  29. >had some SHARED registers between the floating point
  30. >and integer sections, did speculative instruction execution on the alu and
  31. >fpu, provided a 64 bit alu which ops could be segmented into 
  32. >2*32, 4*16, or 8*8 bit concurrent 2's compliment operations, AND ALLOWED THE
  33. >ENTIRE DATA CACHE TO BE BOOT TIME SELECTABLE AS EITHER DATA CACHE OR MEMORY
  34. >MAPPED FAST DATA STORAGE, I'd be happy, and I think it would sell, IMHO. 
  35. >
  36. >-Rich
  37. >
  38. >rstewart@megatek.com
  39.  
  40. All this stuff sounds like nice for imbedded systems, but much of it sounds
  41. pretty useless for general purpose CPUs, at least the part about the segmenting
  42. and the cache mapping.
  43.  
  44. I don't think that the hand pipelining is so bad, although being able to
  45. issue multiple fp instructions without freezing would be fine.  However, I
  46. do agree that the lack of superscalar between the integer, multiplier, and
  47. adder is a problem.  If it were truly superscalar rather than dual-op+dual-mode,
  48. it would be a lot easier to compile to.
  49.  
  50. I still think that good system designs can make the i860 competitive with
  51. existing general-purpose risc chips.
  52. -- 
  53. Larry Meadows        The Portland Group
  54. lfm@pgroup.com
  55.