Author: Robert Hyatt
Date: 17:29:58 07/01/03
Go up one level in this thread
On July 01, 2003 at 16:32:00, Tom Kerrigan wrote: >On July 01, 2003 at 16:04:00, Robert Hyatt wrote: > >>On July 01, 2003 at 13:28:06, Tom Kerrigan 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. >>>> >>>>Conceptually, all of these ISAs can be viewed as "add-ons" or "extensions" if >>>>you're going to make a PowerPoint block diagram, but that has no bearing on the >>>>design of the processor. All of these chips can decode 32 or 64 bit instructions >>>>(with mostly the same logic, in fact) equally fast. Saying "add on" makes it >>>>sound like the 64 bit instructions must first be translated to 32 bit >>>>instructions or something. >>> >>>In fact, even mentioning instruction decoding is misleading here. There's very >>>little difference between decoding (and executing) 32 bit instructions and 64 >>>bit instructions. 32 bit and 64 bit instructions on RISC chips are still the >>>same length (4 bytes) and they're encoded the same way. There are just some >>>extra opcodes/instructions to load the high order bits of registers with >>>immediate values. >>> >>>-Tom >> >> >>Depends. Not _all_ machines use 32 bit instructions. That limits the number >>of registers, for example. And it also means that most memory instructions are >>_way_ long, of course. > >Really? Which RISC computers don't use 32 bit instructions? POWER, Alpha, SPARC, >PA-RISC, MIPS, ARM, and probably some others I'm forgetting all use 32 bit >instructions. Look again. IE addresses stretch the instruction way beyond 32 bits for those instructions that need addresses. The sparc is an easy to find example of this. IE the 32 bit sparc had instructions > 32 bits. >ARM has a 16 bit instruction format to increase code density. I >suppose Itanic uses 40 bits per instruction... rare exception... > >How do 32 bits limit the # of registers? A 3 operand instruction with an 8 bit >opcode can use 8 bits per register = 256 registers. > Simple. You end up with multiple things to fit in the instruction. Opcode which can be 8 bits and up. Registers (sometimes three, sometimes more depending on the machine. IE destination, two sources + an index or a displacement plus an index, etc. I can't think of a single case where an architect said "ok, this is enough bits, there is nowhere I would wish for another couple of bits." That's where the current X86 problems came from, in fact. On the sparc you need 15 bits for the three operands, plus more for the opcode and displacement. On the sparc, one real concession was in the immediate instruction. a 13 bit immediate value is not very useful. To immediately load 64 bit values is a hassle, and this is on a 32 bit version, _not_ on the ultra-sparc 64 bit processor. 32 bit instructions are nice, because for many cases, particular the arithmetic cases (on the sparc) everything fits nicely for things like add r1,r2,r3. And it is certainly a nice design feature to have fixed- length instructions rather than variable-length as on the Cray and the vax to name a couple of well-known variable-length instructions. However, 32 bits does put a box around the overall instruction set architecture, and that box can hurt. As to your specific question, 32 bits _could_ be set up for 8 bits for the opcode, and 8 bits for three registers. But then how do you add 2 to a register? How do you even get 2 into a register other than loading it from memory? The immediate values are useful, but they are too small on the sparc in many cases. Now, for IA-64. An instruction is 128 bits long (an instruction bundle). This contains _three_ 41 bit instructions plus the 5 bit template. That's not exactly 32 bits, so there is another example of non-32bit instruction length. There are others. Fixing on 32 bits is a design decision based on simlifying the pipeline. Nothing wrong with that of course, except for the limits it imposes. >-Tom
This page took 0.02 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.