Author: Tom Kerrigan
Date: 18:02:21 07/01/03
Go up one level in this thread
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. >> 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. >>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. 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? -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.