Index
> Main > x64 is not truly a 64bit procesorGoto page 1, 2 Next |
| Author |
|
|
nop 13 Sep 2012, 02:09
x64 is not truly a 64bit procesor
 |
|||
13 Sep 2012, 02:09 |
|
|
revolution 13 Sep 2012, 04:54
nop wrote: x64 is not truly a 64bit procesor  |
|||
|
13 Sep 2012, 04:54 |
|
|
nop 14 Sep 2012, 09:45
revolution wrote: The x86 encoding mechanism for immediate values only allows 32-bit signed values with ADD in 64-bit mode. |
|||
|
14 Sep 2012, 09:45 |
|
|
revolution 14 Sep 2012, 10:27
nop: x86 is quite rare for the fact that it supports 32-bit immediate values. Many other architectures can't do that. Would you consider IA-64 to be "truly a 64bit processor"?
|
|||
|
14 Sep 2012, 10:27 |
|
|
sinsi 14 Sep 2012, 10:48
>x64 is not truly a 64bit procesor
Pentium MMX was the first 64-bit CPU. Or maybe a 386, that could make 32*32 a 64-bit number. Anyway, who really uses 64-bit integers? |
|||
|
14 Sep 2012, 10:48 |
|
|
nop 14 Sep 2012, 18:33
what wud u think of a 8bit procesor which only allows 4bit immediates
what wud u think of a 16bit procesor which only allows 8bit immediates what wud u think of a 32bit procesor which only allows 16bit immediates so what do u think of a 64bit procesor which only allows 32bit immediates |
|||
|
14 Sep 2012, 18:33 |
|
|
l_inc 14 Sep 2012, 21:21
nop
Quote: what wud u think of a 8bit procesor which only allows 4bit immediates I would think of it as of a completely normal situation. It's actually very uncommon, that an architecture allows immediates of a size equal to the architecture's word length. There're four different RISC-architectures I worked with, and only one (btw. officially undocumented) allowed such long immediates. If you think, it's normal, then please name at least a couple architectures except x86, which allow such long immediates. |
|||
|
14 Sep 2012, 21:21 |
|
|
nop 15 Sep 2012, 04:04
Quote: There're four different RISC-architectures I worked with, and only one (btw. officially undocumented) allowed such long immediates. |
|||
|
15 Sep 2012, 04:04 |
|
|
revolution 15 Sep 2012, 04:20
nop wrote: ... but that is irelevent for cisc procesors of course |
|||
|
15 Sep 2012, 04:20 |
|
|
l_inc 15 Sep 2012, 13:05
nop
Quote: fair enough for risc maybe but that is irelevent for cisc procesors of course Firstly, if it's fair enough for RISC's, then it's fair enough for computer architectures in general, because there's a much larger variety of RISC's then CISC's on the markets. Secondly, even if it's not that common, it's still normal for CISC's. What of those things do we still have on the markets except x86? May be Motorola 68000... well, it allows 32 bit immediates, but not for all instructions (as far as I understand from the short look into the reference manual). The IBM z/Architecture does not allow 64 bit immediates at all. And now Intel 64 on the desktops market does allow 64 bit immediates (mov r64,imm64), but not for all instructions. The architecture's word length corresponds to the size of the applications addressing space (size of a pointer) and nothing else. |
|||
|
15 Sep 2012, 13:05 |
|
|
revolution 15 Sep 2012, 14:06
l_inc wrote: The architecture's word length corresponds to the size of the applications addressing space (size of a pointer) and nothing else. z80 (8-bit CPU) has 16-bit addressing 8086 (16-bit CPU) has 20-bit addressing Many x86 (64-bit CPUs) have 40-bit addressing |
|||
|
15 Sep 2012, 14:06 |
|
|
l_inc 15 Sep 2012, 14:50
revolution
Well. This statement was probably a little inconsiderate, but please, reread it. What you specify for x86 and x64 is a physical address bus width. The applications work however explicitly with pointers of size 32 bit's and 64 bit's accordingly. Regarding Z80, I'm not familiar with it. |
|||
|
15 Sep 2012, 14:50 |
|
|
revolution 15 Sep 2012, 15:04
For 8086 we have a 20-bit pointer (ES:BX generates a 20-bit address) to match the 20-bit bus. Anyhow I was merely pointing out that using pointer size is not the way to measure the bit-ness of a CPU. There are architectures that have different sized pointers, registers and buses. I would expect that in general most people would consider the ALU width to be the measure of bit-ness (old bit-slice CPUs are a prime example).
|
|||
|
15 Sep 2012, 15:04 |
|
|
l_inc 15 Sep 2012, 16:04
revolution
Quote: I would expect that in general most people would consider the ALU width to be the measure of bit-ness. A 32-bit Pentium 4 is able to add 64-bit integer values due to SSE2. A 16-bit dsPIC33F is able to multiply two 16-bit integer values and add the 32-bit result to a 40-bit accumulator with the instruction MAC. The 32-bit MIPS32 has a similar instruction MADD able to multiply 32-bit values and add the result to a 64-bit value. |
|||
|
15 Sep 2012, 16:04 |
|
|
revolution 15 Sep 2012, 21:45
l_inc wrote: A 32-bit Pentium 4 is able to add 64-bit integer values due to SSE2. A 16-bit dsPIC33F is able to multiply two 16-bit integer values and add the 32-bit result to a 40-bit accumulator with the instruction MAC. The 32-bit MIPS32 has a similar instruction MADD able to multiply 32-bit values and add the result to a 64-bit value.  |
|||
|
15 Sep 2012, 21:45 |
|
|
l_inc 15 Sep 2012, 23:03
revolution
Perhaps. Am I wrong assuming, that a 64-bit adder means at least a 64-bit ALU? Or how do you define an ALU width? |
|||
|
15 Sep 2012, 23:03 |
|
|
revolution 15 Sep 2012, 23:24
A MAC unit is not a CPU ALU. A coprocessor accumulator is not a CPU ALU.
If it is not the ALU size then why else is a Z80 8-bit? Why is an 8086 16-bit? Why is a Core-i7 64-bit when it can multiply to 64-bit numbers and get a 128-bit result? I don't think there is any other definition that matches except to consider the ALU of the CPU. |
|||
|
15 Sep 2012, 23:24 |
|
|
l_inc 16 Sep 2012, 14:45
revolution
Quote: A MAC unit is not a CPU ALU. The MAC instruction is executed by the DSP engine, which is a part of the CPU. Quote: A coprocessor accumulator is not a CPU ALU. Not sure, what you mean here. If you mean the SSE/MMX ALU in x86, then it's still a part of the CPU. Btw. the coprocessor is not a separate hardware part of the x86 for almost 15 years. It's referred to as FPU ALU, which is a part of the CPU. And the register's HI and LO on MIPS32 are definitely not a coprocessor accumulator. Quote: If it is not the ALU size then why else is a Z80 8-bit? No idea. 
Quote: Why is an 8086 16-bit? My phlogiston theory was based on the pointers (which I'm ready to give up on). Probably a little far fetched argumentation regarding 8086 is that 8086 still has 16 bits effective addresses explicitly specified by the instructions and segment selectors are a kind of an implicit address part. Quote: Why is a Core-i7 64-bit when it can multiply to 64-bit numbers and get a 128-bit result? Ehm... Aren't you sawing the bough you're sitting on? This should be rather my argumentation, but I wouldn't use it anyway, cause multiplication and division are (almost?) always naturally made to be able to work with the double of the native width. |
|||
|
16 Sep 2012, 14:45 |
|
|
JohnFound 16 Sep 2012, 14:59
Well, my definition: The bit-ness of the CPU is equal to the maximal bit-ness of the source data for "and" instruction. (available on all known CPUs).
 |
|||
|
16 Sep 2012, 14:59 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|