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