Former Intel CPU engineer details how internal x86-64 efforts were suppressed prior to AMD64's success
Former Intel CPU engineer details how internal x86-64 efforts were suppressed prior to AMD64's success
If he "didn't stop yammering about the need to go 64-bits in x86", he'd be fired on the spot
You're viewing part of a thread.
It means pointer width.
https://en.wikipedia.org/wiki/64-bit_computing
64-bit integers, memory addresses, or other data units[a] are those that are 64 bits wide. Also, 64-bit central processing units (CPU) and arithmetic logic units (ALU) are those that are based on processor registers, address buses, or data buses of that size.
It also states Address bus, but as I mentioned before, that doesn't exist. So it boils down to instruction set as a whole requiring 64 bit processor registers and Databus.
Obviously 64 bits means registers are 64 bit, the addresses are therefore also 64 bit, otherwise it would require type casting every time you need to make calculations on them. But it's the ability to handle 64 bit registers in general that counts, not the address registers. which is merely a byproduct.- The whole article overall lacks sources.
- That section is completely unsourced.
- It doesn't say what you think it says.
You were arguing the definition of "X-bit CPU". We're not talking about "X-bit ALU". It's also not up to contention that "A 64-bit integer is 64 bit wide". So, to the statement:
Also, 64-bit central processing units (CPU) and arithmetic logic units (ALU) are those that are based on processor registers, address buses, or data buses of that size.
This does not say which of "processor register, address buses, or data buses" applies to CPU and which to ALU.
Obviously 64 bits means registers are 64 bit, the addresses are therefore also 64 bit,
Having 64 bit registers doesn't necessitate that you have 64 bit addresses. It's common, incredibly common, for the integer registers to match the pointer width but there's no hard requirement in theory or practice. It's about as arbitrary a rule as "Instruction length must be wider than the register size", so that immediate constants fit into the instruction stream, makes sense doesn't it... and then along come RISC architectures and split load immediate instructions into two.
otherwise it would require type casting every time you need to make calculations on them
Processors don't typecast. Please stop talking.
Processors don’t typecast. Please stop talking.
Which is why it's such a pain, because you have to do it manually:
https://lemire.me/blog/2021/10/21/converting-binary-floating-point-numbers-to-integers/I'm sorry are we somehow assuming floating-point pointers, now, of course you need to convert there. "casting" is a specific thing you do in C which may or may not involve conversion of actual data. Processors don't speak C. Processors don't have a type system.
You can use 32-bit pointers in x86_64 long mode, no issue. You don't even need to bit-fiddle:
mov rax, [esi]is perfectly legal. Opcode0x67488B06. Dereferencingrsiwould be0x488B06.I’m sorry are we somehow assuming floating-point pointers, now, of course you need to convert there.
"floating-point pointers" is not a thing:
“casting” is a specific thing you do in C
No it's not:
https://en.wikipedia.org/wiki/Type_conversionIn computer science, type conversion,[1][2] type casting,[1][3] type coercion,[3] and type juggling[4][5] are different ways of changing an expression from one data type to another.
You don't even have a clue, you are just talking trash.
In assembly you don't generally talk about pointers, but address modes. Like register, immediate or memory (indirect).
Have you ever actually been programming any serious assembly? Because you sure don't sound like it.
Great! Now please explain how opcodes are expressions. Also, what processor instruction a cast from one pointer type to another pointer type corresponds to.
You are way out of your depth here. Have you even implemented a compiler.
EDIT:
You don’t even have a clue, you are just talking trash.
In assembly you don’t generally talk about pointers, but address modes. Like register, immediate or memory (indirect).
Have you ever actually been programming any serious assembly? Because you sure don’t sound like it.
Oh cute edit to make to make my response look bad retroactively.
But as you wanted to get pedantic: A pointer is a value which is intended to be dereferenced, that (hopefully) corresponds to a valid memory address. "address", "pointer", "reference", it's a matter of taste which one you use. It exists "in assembly" just as "an index" exists in C: Not because it's a language feature, but because it's a concept you use when writing in the language. And yes I speak pretty fluent x86, at least the non-SIMD part. Did I mention that I was there, at ground zero "why is is thing not compiling in 64 bit mode" times, fixing code?
Now, back to my question:
what processor instruction does a cast from one pointer type to another pointer type corresponds to.
Figuring out the answer to that will tell you everything you need to know about where you went wrong. Where you went from talking about actual concepts to arguing semantics.
Processors don’t typecast. Please stop talking.
Yes they do, for instance between signed and unsigned integers. Just because it's done by the programmer choosing the correct instruction, doesn't mean it's not equivalent to typecasting.
OK so how do you imagine you do calculations on addresses in a 3 dimensional matrix, with 64 bit integer calculations, and then when they are to be copied to address registers would work?
And how would it work when you copy an only 40 bit value to a 64 bit register? Are the remaining 24 bits cleared, or do they stay the same? The answer is neither, because it doesn't exist.Your arguments are based on fantasy with no foundation in reality of how a CPU works.
Obviously today you are copying a 64 bit value to a 64 bit register, both ways!!
But if you try the same from a 64 bit value you can't move that to a 16 bit register. The command doesn't exist. Because it would be nonsense. To move a 16 bit value to a 16 bit register, you can ONLY do that with an instruction for 16 bit values.
The same would have to be true for 40 bit address values.
So either the CPU would have to strip the extra bits, which means the integrity of the data is lost in some situations. Or you would have to do some form of the equivalent to typecasting.
Maybe having a special move instructions for 40 bit values.
There's a reason address registers are the same length as integers. There's a reason they are the same length whether direct or indirect, and there's a reason they remain the same length whether relative or absolute.Maybe you should just admit you were wrong from the start, because your claims are nonsensical.