home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10947 < prev    next >
Encoding:
Internet Message Format  |  1992-11-19  |  2.4 KB
  1. From: maf@hpfcso.FC.HP.COM (Mark Forsyth)
  2. Date: Thu, 19 Nov 1992 17:28:29 GMT
  3. Subject: Re: DEC Alpha AXP System INTEGER Performance
  4. Message-ID: <8840086@hpfcso.FC.HP.COM>
  5. Organization: Hewlett-Packard, Fort Collins, CO, USA
  6. Path: sparky!uunet!wupost!sdd.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!hplextra!hpfcso!maf
  7. Newsgroups: comp.arch
  8. References: <1698@niktow.canisius.edu>
  9. Lines: 40
  10.  
  11.  
  12. In comp.arch, blair@snogum.enet.dec.com (Blair Phillips - Digital) writes:
  13. > 
  14. > A good example is the lack of 8 and 16 bit load and store instructions.
  15. > Providing these would have added a complex multiplexor in the critical path
  16. > from the internal cache to the register file. It would have forced either a
  17. > longer cycle time, or an extra cycle for *all* load/store instructions.
  18.  
  19. I've been hearing about this claimed architectural advantage for months now
  20. but still don't get it.  For example:
  21.  
  22. 1) why is the cache to register file path so critical in the alpha chip ?  
  23. this is not the case with all microprocessors.  especially the store path - 
  24. I thought that address generation was usually tougher.  is this another
  25. "superpipelining" dividend ?
  26.  
  27. 2) multiplexers can be made VERY fast -  they only add a transfer gate and
  28. wire delay in the data path (or you can just use the transfer gate already
  29. needed for the register input). why not just speed up this circuit, or take 
  30. a slight amount of time from the cache access (should be easy with on-chip 
  31. primary cache) or register setup time ? or add another transparent data 
  32. latch in front of the multiplexer so it can be done in a different clock 
  33. cycle ?  perform the multiplexing in existing cache circuits ?  (your idea
  34. here) ? 
  35.  
  36. 3) is it really forward looking to modify the instruction set because one
  37. circuit design had trouble meeting its speed budget ?  isn't it conceivable
  38. that other implementations won't have the same critical speed path ?
  39.  
  40. Do other processor designers see any fundamental speed advantage for alpha 
  41. due to this decision ?  Alpha certainly is fast, but I would guess that this
  42. is due more to the long pipeline, the special VLSI technology DEC developed, 
  43. a willingness to sort out the very fastest parts in the speed distribution 
  44. for the mainframe version (even DEC says 200MHz is not available "in volume") 
  45. and good circuit designers rather than instruction-set wizardry.  It is 
  46. unfortunate that marketeers can't be satisfied with just good engineering.
  47.  
  48. - Mark Forsyth   (my opinions, not HP's) 
  49.   maf@fc.hp.com
  50.  
  51.