Author: Robert Hyatt
Date: 11:18:47 07/02/03
Go up one level in this thread
On July 01, 2003 at 21:02:21, Tom Kerrigan wrote: >On July 01, 2003 at 20:34:08, Robert Hyatt wrote: > >>>You, and many other people, seem to be surprised that the Opteron can execute 32 >>>bit code at "full speed." >> >>Not really. What I suggested was that without the 32 bit kludges, it could >>probably execute 64 bit code _faster_. > >What kludges? I can't think of any 32-bit-mode logic that would add more than >one gate delay, and what are the chances that that gate delay would end up in >the critical path, i.e., it's in the longest pipeline stage and it can't be done >in parallel with anything else? Might as well be zero, I figure. I can think of "several kludges". sign flag. Which bit does it come from? There are currently 4 choices, depending on byte, word, doubleword, or now quadword. Hard to choose one of four bits in one gate delay time. > >>> This is confusion that Intel has generated in the >>>recent past with Itanic. Intel makes it sound like they invented 64 bit >>>processors and people believe that 32 bit code can't run well on 64 bit >>>processors because x86 code runs like shit on IA64 chips. This is simply because >>>INTEL CHANGED THE ENTIRE ISA, not just the datapath width of the chip. In fact, >>>there really should be no reason to expect 32 bit code to run slower on a 64 bit >>>processor than 64 bit code. >> >>No, but again, it is reasonable to expect that the 64 bit stuff _could_ run >>even faster if it didn't have the 32 bit stuff wrapped in. But intel is not >>the only one that has clouded the 32/64 bit understanding a bit. The alpha >>was another example. And then sun's sparc/ultrasparc that is probably the > >How did Alpha do that? Alpha was never a 32 bit ISA. > It definitely supports 32 bit instructions, as well as all the way down to bytes. The cray doesn't, as a counter-point. >>>Back when I designed my own processor in college, I had a variable that >>>controlled the datapath width. I could change the processor from, say, 12 to 16 >>>bits by changing 1 character. It would have probably only taken a couple of >>>hours to add a "mode" flag to allow the processor to execute both 12 and 16 bit >>>code with no performance penalty. This is exactly what Sun, IBM, HP, etc. did in >>>the mid-90s and what AMD is doing now with x86. >> >>However, on a _full_ processor implementation you have significant problems >>trying to do that. IE shifts. Rotates. They become messy. As does other >>things. > >I hadn't thought of that. (It's amazing that it takes you so many posts to get >warmed up enough to say something intelligent.) It seems like the logic that >differentiates shifting and rotating in a shifter (i.e., zeroing or extending >depending on the amount shifted) is already doing something very similar to what >would be necessary to handle both 32 and 64 bit shifts. > It's just complex. IE rotate through carry, as an example. Where does that carry bit come from, and where does it go? That's gross. The condition code is another issue, although not all machines have such a thing. >My processor did shifts and rotates, BTW, but with a counter, like early RISC >designs. Shifting arbitrary word sizes wouldn't have been a problem. > >What are the other things? > All the way back to atomic test/set/exchange operations. The counter approach is perfectly ok, but it introduces yet another delay. However since the PIV seems to be a bad "shifter" maybe Intel is listening to your idea. :) >-Tom
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.