384
Former Intel CPU engineer details how internal x86-64 efforts were suppressed prior to AMD64's success
(www.tomshardware.com)
this post was submitted on 19 Oct 2024
384 points (99.0% liked)
Technology
59589 readers
2962 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Everybody in the know, knows that x86 64 bit was held back to push Itanium, Intel was all about market segmentation, which is also why Celeron was amputated on for instance RAM compared to Pentium.
Market segmentation has a profit maximization motive. You are not allowed to use cheap parts for things that you are supposed to buy expensive parts for. Itanium was supposed to be the only viable CPU for servers, and keeping x86 32 bit was part of that strategy.
That AMD was successful with 64 bit, and Itanium failed was Karma as deserved for Intel.
Today it's obvious how moronic Intel's policy back then was, because even phones got 64 bit CPU's too back around 2009.
32 bits is simply too much of a limitation for many even pretty trivial tasks. And modern X86 chips are in fact NOT 64 bit anymore, but hybrids that handle tasks with 256 bits routinely, and some even with 512 bits, with instruction extensions that have become standard on both Intel and AMD
When AMD came with Ryzen Threadripper and Epyc, and prices scaled very proportionally to performance, and none were artificially hampered, it was such a nice breath of fresh air.
On a note of technical correctness: That's not what the bitwidth of a CPU is about.
By your account a 386DX would be an 80-bit CPU because it could handle 80-bit floats natively, and the MOS6502 (of C64 fame) a 16-bit processor because it could add two 16-bit integers. Or maybe 32 bits because it could multiply two 16-bit numbers into a 32-bit result?
In reality the MOS6502 is considered an 8-bit CPU, and the 386 a 32-bit one. The "why" gets more complicated, though: The 6502 had a 16 bit address bus and 8 bit data bus, the 368DX a 32 bit address and data bus, the 368SX a 32 bit address bus and 16 bit external data bus.
Or, differently put: Somewhere around the time of the fall of the 8 bit home computer the common understanding of "x-bit CPU" switched from data bus width to address bus width.
...as, not to make this too easy, understood by the instruction set, not the CPU itself: Modern 64 bit processors use pointers which are 64 bit wide, but their address buses usually are narrower. x86_64 only requires 48 bits to be actually usable, the left-over bits are required to be either all ones or all zeroes (enforced by hardware to keep people from bit-hacking and causing forwards compatibility issues, 1/0 IIRC distinguishes between user vs. kernel memory mappings it's been a while since I read the architecture manual). Addressable physical memory might even be lower, again IIRC. 2^48^B are 256TiB no desktop system can fit that much, and I doubt the processors in there could address it.
And how do you figure that? The Intel 80386DX did NOT have any 80 bit instructions at all, the built in math co-processor came with i486. The only instructions on a 80386DX system that would be 80 bit would be to add a 80387 math co-processor.
But you obviously don't count by a few extended instructions, but by the architecture of the CPU as a whole. And in that regard, the Databus is a very significant part, that directly influence the speed and number of clocks of almost everything the CPU does.
You're right, I misremembered.
For those old processors, yes, that's why the 6502 was 8-bit, for modern processors, though? You don't even see it listed on spec sheets. Instead, for the external stuff, you see number of memory controllers and PCIe lanes, while everything internal gets mushed up in IPC. "It's wide enough to not stall the pipeline what more do you want" kind of attitude.
Go look at anything post-2000: 64 bit means that pointers take up 64 bits. 32 bits means that pointers take up 32 bits. 8-bit and 16-bit are completely relegated to microcontrollers, I think keeping the data bus terminology, and soonish they're going to be gone because everything at that scale will be RISC-V, where "RV32I" means... pointers. So does "RV64I" and "RV128I". RV16E was proposed as an April Fool's joke and it's not completely out of the question that it'll happen. In any case there won't be RV8 because CPUs with an 8-bit address bus are pointlessly small, and "the number refers to pointer width" is the terminology of . An RV16 CPU might have a 16 bit data bus, it might have an 8 bit data bus, heck it might have a 256bit data bus because it's actually a DSP and has vector instructions. Sounds like a rare beast but not entirely nonsensical.
Doesn't mean it's any less important, it's just not a good marketing measure,because average people wouldn't understand it anyway, and it wouldn't be correct to measure by the Databus alone.
As I stated it's MORE complex today, not less, as the downvoters of my posts seem to refuse to acknowledge. The first Pentium had a 64 bit Databus for a 32 bit CPU. Exactly because data transfer is extremely important. The first Arm CPU was designed around as fast RAM access/management as possible, and it beat the 386 by several factors, with a tenth the transistors.
Although true, this is a very simplistic way to view it, and not relevant to the actual overall bitwith of the CPU, as I've tried to demonstrate, but people apparently refuse to acknowledge.
But bit width of the Databus is very important, and it was debated heavily weather it was even legal to market the M68008 Sinclair QL as a 32 bit computer, because it only had an 8 bit databus.
But as I stated other factors are equally important, and the decoder is way more important than the core instruction set, and modern higher end decoders operate at 256 bit or more, allowing them to decode multiple ( 4 ) instructions per cycle, again allowing each core to execute multiple instructions per clock, in 2 threads. Without that capability, each core would only be about a third as fast.
To claim that the instruction set determines bit wdth is simplistic, and also you yourself argued against it, because that would mean an i486 would be an 80 bit CPU. And obviously todays CPU's would be 512 bit, because they have 512 bit instructions.
Calling it 64 bit is exclusively meant to distinguish newer CPU's from older 32 bit CPUS, and we've done that since the 90's, claiming that new CPU architectures haven't increased in bit width for 30 years is simply naive and false, because they have in many more significant ways than the base instruction set.
Still I acknowledge that an AARCH64 or AMD64 or i64 CPU are generally called 64 bit, it was never the point to refute that. Only that it's a gross simplification of what modern CPU's have become, and that it's not technically correct.
Let me finish with a question:
With a multi-core CPU where each core is let's just say 64 bit, how many bits is the whole CPU package? Which is what we call the "CPU" today, when saying CPU we are not generally talking about the individual cores, because then it would have to be plural.
The reason you're getting downvoted is because you're saying that "64-bit CPU" means something different than is universally acknowledged that it means. It means pointer width.
Yes, other numbers are important. Yes, other numbers can be listed in places. No, it's not what people mean when they say "X-bit CPU".
RV128 exists. It refers to pointer width. Crays existed, by your account they were gazillion-bit machines because they had quite chunky vector lengths. Your Ryzen does not have a larger "databus" than a Cray1 which had 4096 bit (you read that right) vector registers. They were never called 4096 bit machines, they Cray1 has a 64-bit architecture because that's the pointer width.
Yes, the terminology differs when it comes to 8 vs. 16-bit microcontrollers. But just because data bus is that important there (and 8-bit pointers don't make any practical sense) doesn't mean that anyone is calling a Cray a 4096 bit architecture. You might call them 4096 bit vector machines, and you're free to call anything with AVX2 a 256-bit SIMD machine (though you might actually be looking at 2x 128-bit ALUs), but neither makes them 64-bit architectures. Why? Because language is meant for communication and you don't get to have your own private definition of terms: Unless otherwise specified, the number stated is the number of bits in a pointer.
https://en.wikipedia.org/wiki/64-bit_computing
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.
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:
This does not say which of "processor register, address buses, or data buses" applies to CPU and which to ALU.
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.
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."floating-point pointers" is not a thing:
No it's not:
https://en.wikipedia.org/wiki/Type_conversion
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:
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:
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.
Where did you get that from? Because that's false, please show me dokumentation for that.
64 bit always meant the ability to handle 64 bit wide instructions, and because the architecture is 64 bit, the pointers INTERNALLY are 64 bit, but effectively they are only for instance 40 bit when accessing data.
Your claim about pointer width simply doesn't make any sense.
That the CPU should be called by a single aspect they can't actually handle!!! That's moronic.
People literally use the word "literally" to mean figuratively. It doesn't make any sense. One might even call it moronic.
But it's the way it's done. Deal with it.