It's basically MIPS all over again
The conclusion is honest, and you can of course brute force any ISA into any role. I used to loathe x86 for that reason, but now that I'm older I respect the game.
It's basically MIPS all over again
The conclusion is honest, and you can of course brute force any ISA into any role. I used to loathe x86 for that reason, but now that I'm older I respect the game.
X86 is the best argument that you can build a fast efficient RISC-V chip... because the X86 instruction set is a much bigger mess.
It just blows my mind sometimes when designers don't learn insanely obvious lessons from the past, basic stuff like "complexity is evil" and "make the fast path overlap with the most common use cases" and "a standard with N optional extensions is actually N! (N factorial) standards."
That being said all real world architectures seem to have messy corners and warts. RISC-V was a chance to do away with a lot of that and they... didn't?
> because the X86 instruction set is a much bigger mess.
One of the things I've been playing with off and on in my spare time is poking at the x86 ISA. And yet, while the ISA does have some weirdness to it, it is a lot less weird than its reputation makes it out to be. For example, the sum total of the opcode form amounts to does-it-have-ModR/M + size of immediate operand (in bytes)... which honestly strikes me as simpler than RISC-V instruction form decoding.
I know there's an earlier criticism of RISC-V that points out that one of the common instruction sequences for which "macro-op fusion" is the suggested solution involves 5 instructions... and I don't think any of the existing chips ever fuse more than 3 instructions?
You've also got tons of prefixes with opcode dependent rules on what's allowed there, the opcode field itself is variable length (I've seen up to four bytes), you've got instructions that treat that immediate field as additional opcode bytes, etc.
The opcode is 5 maps (8, actually, but only 5 are occupied) of 10-bit opcodes, with the presence or absence of 66/F2/F3 prefixes providing 2 of those bits. If you ignore how the manual describes prefixes and look at it like that (which is suggested by the VEX encoding process), the decoding process becomes a lot simpler. In fact, with one singular exception, this is sufficient information to index into a map to figure out how long the immediate field is and whether or not ModR/M is present.
> X86 is the best argument that you can build a fast efficient RISC-V chip... because the X86 instruction set is a much bigger mess.
I don't think that's actually true. There's weird historical baggage and whatnot. But if you're running in long mode, it's actually a fairly sensible architecture with useful memory addressing modes.
They even loudly declared how they were going to clean up all the messy corners and warts.
The underlying truth seems to be that a “clean” ISA doesn’t by nature make the beer taste better, and many of the warts probably have a reason for existing.
There is a general pattern I've noticed, where people from past generations fail to share the lessons they have learned somewhere that is accessible for the next generations, so they are stuck repeating the lesson.
In particular, the next generation might recognize some aspects that seem bad and be confused over how to prioritize correctly because they don't know any better.
But they do share it.
It is just that it is some combination of behind closed doors, for competitive advantage, and/or the new generations don’t want to hear it.
Previous generations had learned long ago that sharing everything in public, or even in patents, was a bad idea for long term survival, a lesson that has now taken on a more extreme form.
2^N I think, but who's counting.
I think MIPS is a great example, and even there I don't think there's the bizarre bifurcation of ISA options RISC-V brings to the table.
As a fellow olderster, I can't help but think that after almost 50 years of "ISA X is sooooo much better than x86 it's obvious ISA X is the future and x86 will be dead Real Soon Now (for whatever todays version of x86 is)" I can only shake my head ruefully and say "ping me when that happens".
Controversial Take (that history proves isn't): Software matters; ISAs don't.
x86 chips don't truly exist anymore. They only use it as a compressed ISA for a more capable internal representation that can be freely updated at any time.
I keep seeing this line of reasoning and have no idea why it's relevant. You don't program that 'internal representation'. The software people want to run only care if that software doesn't run. Cyrix, Transmeta,NexGen, Centaur, WinChip, etc., etc, theoretically had "more capable internal representation". The only thing that actually matters is "does it run the exact same x86 software I bought X many years ago" and "does it run it at a decent price/performance ratio". Everything else is dick measuring.
Today, we have Intel and AMD, and some bit-player embedded folks.
There's still repercussions to the unaligned variable length instruction set that is x86 though, and the decoder and prefetch have to deal with the insanity that falls out from it... ultimately limiting how parallel the instruction decode and dispatch can be.
This is a load of bullshit that largely exists as copium to explain how x86 did the impossible and made a superscalar CISC processor. x86 is doing the same thing that (to my knowledge) all high-end processors do, yet no one tries to call out those chips as compiling to a different internal ISA. But you also don't see any chips trying to run with multiple ISA modes: the closest you get is 32-bit and 64-bit modes coexisting, or ARM's Thumb instruction set.
I haven't kept up with POWER after POWER9, but I recall it to be a true hardwired control RISC, pure as the driven snow. This had some interesting properties (along with other clever designs like eFuses and pNOR) for creating a really credible security posture. They do have a millicode system and chicken bits for oops moments (which are kind of an opposite risk, if you don't get those right for unexpected problems).
Amen. I remember the about 6 months when the benchmark cawboys were screaming that they had to be able to have access to directly program the Pentium Pro micro-instructions because 'that would be so much faster' and no matter how much the Intel architects who actually knew how things worked said "I don't think those words mean what you think they mean" there was some conspiracy to keep the PPro from achieving it's max performance...as if Intel didn't want the PPro to show it's max performance.
Humans are weird.
Sort of.
They always had a much cleaner instruction set internally, going back to the 8086.
Whenever I see someone say this I'm thinking the following:
If what they say is true, then x86 won because ISA doesn't matter, precisely because ISA is the public instruction set architecture. If you can convert anything to a better representation then the argument of exposing the better representation doesn't actually follow.
Additionally, you are claiming that an internal implementation detail that only Intel and AMD know about is secretly implementing your favourite instruction set, which when you think about it, is incredibly implausible and impossible to prove. It's eerily similar to an unfalsifiable theological claim.
Then there is the silly argument that x86 chips don't exist anymore, when x86 chips have distinctive differentiating factors that make them unlike chips that implement other ISAs. The most obvious one is that x86 is primarily used in the personal computing and server space. This means the chips focus on high single threaded performance with large caches and large core counts plus swappable memory and storage devices, whereas most ARM and RISC-V devices target a completely different space, primarily embedded devices where everything is included on the PCB and there are very few external interfaces. You have to be pretty delusional that an unfalsifiable claim on an internal architectural detail of a CPU core somehow invalidates the rest of the silicon that happens to be on the same die.
I hate comments like yours because they are self defeating and require a lot of effort to debunk.