Author: Robert Hyatt
Date: 17:34:08 07/01/03
Go up one level in this thread
On July 01, 2003 at 19:02:29, Tom Kerrigan wrote: >On July 01, 2003 at 18:12:17, Robert Hyatt wrote: > >>On July 01, 2003 at 16:45:20, Tom Kerrigan wrote: >> >>>On July 01, 2003 at 16:02:40, Robert Hyatt wrote: >>> >>>>On July 01, 2003 at 13:20:32, Tom Kerrigan wrote: >>>> >>>>>On July 01, 2003 at 11:57:58, Robert Hyatt wrote: >>>>> >>>>>>On June 30, 2003 at 21:03:30, Tom Kerrigan wrote: >>>>>> >>>>>>>On June 29, 2003 at 23:50:11, Robert Hyatt wrote: >>>>>>> >>>>>>>>On June 29, 2003 at 06:35:02, Tony Werten wrote: >>>>>>>> >>>>>>>>>On June 28, 2003 at 14:23:50, Robert Hyatt wrote: >>>>>>>>> >>>>>>>>>>On June 28, 2003 at 12:12:15, Jay Urbanski wrote: >>>>>>>>>> >>>>>>>>>>>On June 28, 2003 at 10:33:45, Robert Hyatt wrote: >>>>>>>>>>> >>>>>>>>>>>>Those are not true 64 bit processors. Supposedly 32 bit stuff runs just >>>>>>>>>>>>fine on them, but they have 64 bit extensions. >>>>>>>>>>> >>>>>>>>>>>How is Opteron not a true 64-bit processor? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Because it executes 32 bit instructions _also_. >>>>>>>>> >>>>>>>>>P4 and AMD also execute 16-bit instructions, so they are 16 bit processors ? >>>>>>>> >>>>>>>>Not pure 16 bit no. Not pure 32 either. >>>>>>>> >>>>>>>>Check out "Cray" for a better example of a pure architecture. >>>>>>>> >>>>>>>>All math is 64 bits. All address arithmetic is 32 bits. Different >>>>>>>>instructions, functional units, and registers for each. No kludges about >>>>>>>>gating 32 bits with 32 high-end zeroes and that kind of stuff. >>>>>>>> >>>>>>>>But in the case of opteron, at least at first look, it appears to be a 32 >>>>>>>>bit machine with 64 bit instructions layered on top. >>>>>>> >>>>>>>Are you kidding me? >>>>>>> >>>>>>>The "bitiness" is the width of a chip's datapath, right? >>>>>> >>>>>>Yes. But there is more. A chip made to do 64 bit operations as its _normal_ >>>>>>mode of functioning is a 64 bit chip. A chip that does 32 bit operations >>>>>>normally, with 64 bit add-ons, is not really a _full_ 64 bit chip. >>>>>> >>>>>>That was, and is, my point. >>>>> >>>>>How do you figure that the Opteron/PA-RISC/UltraSPARC/MIPS/POWER do not do >>>>>64-bit operations as their "normal" mode of functioning? They have 64 bit >>>>>registers and the values in those registers are communicated over 64 bit busses >>>>>to 64 bit buffers and 64 bit latches and 64 bit ALUs. How can you possibly get >>>>>more 64 bit than that? Just because all of this hardware _can_ be utilized to >>>>>also execute 32 bit instructions (the same way a chip does a "2 bit instruction" >>>>>when you calculate the sum of 1 + 1) doesn't mean it's not a 64 bit chip. >>>> >>>>No, but it _very likely_ means that the design has some trade-offs to make the >>>>32 bit stuff work. IE it is simply easier to do everything in 64 bit mode >>>>rather than having to special-case some 32 bit stuff using the same registers, >>>>as then there are all the normal sign-bit problems, to name just one issue. >>> >>>Yes, there are some sign issues and some flag bit issues but if you know >>>anything about logic design you know those are insignificant. Alpha is a pure 64 >>>bit chip and it still has to do sign extension stuff for when you load 8, 16, or >>>32 bit values and want them sign-extended. So you can reuse logic that's already >>>there. I refuse to believe that 32 bit support in any of these chips involves >>>trade-offs in any way. >>> >>>>>>It runs X86 natively. That is a 32 bit instruction set. >>>>> >>>>>So does IA64, although you apparently didn't realize this. >>>> >>>>No I didn't, although I am not an IA64 person. However, how does a VLIW >>>>architecture execute mov al,x type instructions? If the hardware can do >>>>that it would be interesting. If software has to do some translation then >>> >>>The same way a RISC architecture (e.g., Pentium 4) executes mov al,x type >>>instrcutions. >>> >>>-Tom >> >> >>The problem is, the X86 architecture _defines_ mov al,x. But I don't see >>that in the VLIW definition for Itanium... Not that I intend to be an >>Itanium assembly programmer any time soon unless we get a few and they are >>available for chess. :) > >Itanium differs from PA, POWER, Opteron, etc. in that its primary, EPIC >instruction set is completely different from x86 (obviously). When running x86 >code, special logic must be used to translate x86 instructions to EPIC, the same >way the P4 uses special logic to translate x86 to uops. (The difference being >that the translation step can be circumvented with Itanium, which is good, >because x86 performance on Itanium is shit.) > >Of course, PA, Opteron, etc. don't need to do any sort of translations because >the 32 and 64 bit instruction sets are effectively the same, e.g., if you have >the instruction > >add r1, r2, r3 > >with MIPS, the instruction is exactly the same regardless of the program being >32 bit or 64 bit. What does it do? Reads the 64 bit value out of r1 (even in 32 >bit mode), reads the 64 bit value out of r2, adds them with its 64 bit ALU, and >writes the 64 bit result to r3. The difference being a couple of gates that set >the condition flags differently depending on the mode and a couple of gates to >do sign extension while writing the result back in 32 bit mode. (Did I forget >anything?) > >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_. > 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 worst 64 bit chip around performance-wise. > >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. > >-Tom However, on a _full_ processor implementation you have significant problems trying to do that. IE shifts. Rotates. They become messy. As does other things.
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.