3 ms·

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, bu

by kev009 2mo ago

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.

kjs3 2mo ago
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.
- kevin_thibedeau 2mo ago
  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.
  - kjs3 2mo ago
    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.
  - monocasa 2mo ago
    Sort of. They always had a much cleaner instruction set internally, going back to the 8086.
  - jcranmer 2mo ago
    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.
    - kjs3 2mo ago
      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.
    - kev009 2mo ago
      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).
      - peterfirefly 2mo ago
        A lot of the implementations have used cracking and grouping. They were/are definitely not doing anything like a 1-to-1 mapping between externally visible instructions and their implementation.
  - imtringued 2mo ago
    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.
  - bfrog 2mo ago
    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.
api 2mo ago
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?
- rayiner 2mo ago
  > 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.
- jcranmer 2mo ago
  > 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?
  - monocasa 2mo ago
    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.

by kev009 2mo ago

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.

kjs3 2mo ago

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.

kevin_thibedeau 2mo ago
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.
- kjs3 2mo ago
  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.
- monocasa 2mo ago
  Sort of. They always had a much cleaner instruction set internally, going back to the 8086.
- jcranmer 2mo ago
  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.
  - kjs3 2mo ago
    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.
  - kev009 2mo ago
    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).
    - peterfirefly 2mo ago
      A lot of the implementations have used cracking and grouping. They were/are definitely not doing anything like a 1-to-1 mapping between externally visible instructions and their implementation.
- imtringued 2mo ago
  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.
- bfrog 2mo ago
  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.

api 2mo ago

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?

rayiner 2mo ago
> 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.
jcranmer 2mo ago
> 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?
- monocasa 2mo ago
  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.