home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6688 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.5 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Sat, 30 Mar 96 23:04:01 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: AB3D II beats Quake....
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4ph5@grafix.xs4all.nl>
  11. Organization: Private
  12.  
  13. In a message of 28 Mar 96 Stephan Schaem wrote to All:
  14.  
  15.  >> On CISC, it's  not possible, because opcode are not 32 bit aligned. This
  16.  >> means that before decoding intstruction i, you must decode instructions 0
  17.  >> to i-1.
  18.  
  19.  SS> Thats not a problem really... x86 nowdays have a risc core and decode
  20.  SS> the x86 'language'. I heard that maybe 18% of the P6 is actually
  21.  SS> x86 related the rest is just risc design.
  22.  
  23. Actually I heard that the P6 just decodes EVERYTHING which might be an x86
  24. instruction and if it later turns out that it actually wasn't a real
  25. instruction (because an earlier instruction was longer than 1 byte) it just
  26. discards the results of the fake instructions.  That's wasting an incredible
  27. amount of power.
  28.  
  29.  >> This way RISC can also implement powerful branch prediction, which tend
  30.  >> to add no overhead whether the branch is taken or not. Such prediction
  31.  >> technology are not usable in CISC ; using them would mean adding thousand
  32.  >> of transistors that could be used to speed up other instructions.
  33.  
  34.  SS>  The P6 seem to show that cisc with alot of effort can perform pretty
  35.  SS> well.
  36.  
  37. Sure, but I bet it costs Intel more than 10 times as much money to get the P6
  38. to perform as well as the PPC604.  Just think of what the PPC604 could have
  39. been with 10 times as large a budget.  Also I think integrating a huge cache on
  40. the chip had a LOT more to do with the current performance of the P6 (and of
  41. course the usual overinflated Intel specmarks).
  42.  
  43.  >> Again, I don't agree. The problem is not the size of the opcode, but the
  44.  >> time needed to execute it. Allowing 1 byte opcode means you won't be able
  45.  >> to do pipelining and predecoding of the instructions flow. I don't think
  46.  >> any chip firm today would go that way, ie using 1 byte opcode.
  47.  
  48.  SS>  Its hard to say what would be the best instruction size/format...
  49.  
  50. Maybe, but I think there are definitely very good reasons not to use 16 bit or
  51. 8 bit instructions sizes anymore.
  52.  
  53.  >> >Intel is not dumb, they said 3 years ago what I understood nowadays.
  54.  >> >Time for other people to understand it as well. >
  55.  >> Intel is producing mass CPU, not clever CPU. I'm much more interested in
  56.  >> work and advices from HP, MIPS, ...
  57.  
  58.  SS> Intel also design advance risc that even SGI used for high end
  59.  SS> geometry engine. HP also use intel risc in mass quatity. Intel
  60.  SS> is not stupid and has ALOT of resource to take crap design like
  61.  SS> the x86 and turn it around to be a performer.
  62.  
  63. Performer?  Why not divide the 'performance' by the price-tag and compare it
  64. with other chips.
  65.  
  66.  >> One of the big problem with the x86, is the poor number of register and
  67.  >> the way they have to be used. Really, having 32 or 64 regs (PPC) greatly
  68.  >> helps speeding up execution (as an  ASM supporter, I think you will agree
  69.  >> on the importance of the number of registers).
  70.  
  71. C compilers like lots of registers as well, especially if they are general
  72. purpose registers.  It not only makes good compilers easier to write (there are
  73. a lot less rules to be taken into account), it probably also makes for faster
  74. compile times (less special cases to check and optimize).
  75.  
  76. Grtz John
  77. -- Via Xenolink 1.985B5, XenolinkUUCP 1.1
  78.