4 ms·

Yep. And then we learned that transistors were almost free, could be purchased in lot quantities of 1 billion, and could be used to create a translation layer b

Yep. And then we learned that transistors were almost free, could be purchased in lot quantities of 1 billion, and could be used to create a translation layer between a CISC instruction stream and a RISC core.

rjsw 1y ago
Not for VAX, see the recent thread on it [1]. [1] https://news.ycombinator.com/item?id=45378413 https://news.ycombinator.com/item?id=45378413
- drob518 1y ago
  I’m not sure I get your point? Are you saying it is impossible to accelerate the VAX instruction set via the same technique used on x86? If so, you’ll have to explain why. Now, whether you’d want to or not is another question.
  - p_l 1y ago
    Yes, it's not possible to do it the same way, because what made x86 successful in their application is that x86 was remarkably RISC-y in actual behaviour compared to 68k or VAX. The main reason for that is that x86 code, outside of being register poor leading to lots of stack etc. use, decomposes most "ciscy" operations into LEA (inlined in pipeline) + memory access + actual operation. VAX (and to lesser extent, m68k and others) had multiple indirections just to get the operands right, way more than what is essentially single LEA instruction. The most complex VAX instructions could have been ignored as "this is super slow one and rarely used", but the burden of handling the indirections remain, including possible huge memory latency costs.
    - clausecker 1y ago
      Also, the VAX instruction encoding is a class of horror above that of x86.
      - p_l 1y ago
        few classes above. Only ISA where I've seen a single instruction span two memory pages despite being page aligned
        brucehoult 1y ago
        Two cache lines, sure, on earlier models, but not two VM pages!! Maximum instruction length is 56 bytes. Early models had 8 byte cache lines, later ones 64 bytes. VM page 512 bytes.
        p_l 1y ago
        I might be mistaken then, but I recall reading something about most extreme decode on VAX going into ~522 bytes. What I am more certain of was complaints about possibly ending with maaaany TLB lookups (and pagetable walks) for certain "business" optimized instructions.
        brucehoult 1y ago
        Absolutely. Six operands [1], each of which can be in a different memory page AND have an indirection via another memory page AND both the indirection and the final operand could if you're unlucky be misaligned and straddle two memory pages ... ow. [1] MOVTC (Move Translated Character), MOVTUC (Move Translated Until Character), ADDP6 (Add Packed 6-operand)
        p_l 1y ago
        I think it was implied to me that every operand of ADDP6 could have been indirected, and all the resulting 3 ranges all could straddle pages.
hajile 1y ago
Transistors aren’t free. x86 cores are all bigger than their ARM competitors even when on the same node while also getting worse performance per watt. The translation layers cost time and money to build which could be spent making the rest of the chip faster. They stuck up extra die area and use power. ARM’s total income in 2024 was half of AMDs R&D budget, but the core they finished that year can get x86 desktop levels of performance in a phone. The idea that there’s no cost to x86 just doesn’t seem to hold up under even mild scrutiny.
- buildbot 1y ago
  This is not really true. For example, an Apple M1 has firestorm cores that are around 3.75mm^2, and a zen3 core from around the same era is just 3mm^2 (roughly). I can make a silly 20 wide arm cpu and a silly 1 wide x86 cpu and the x86 will be smaller by a lot.
  - hajile 1y ago
    Where did you get your numbers? M1 core is 2.28mm2 and Zen3 core is 4.05mm2 if you count all the core-specific stuff (and 3.09mm2 even if you exclude the power regulation and the L2 cache that only this core can use). That is 27-45% larger for generally worse performance (and all-around worse performance if per-core power is constrained to something realistic). I'd also note that Oryon and C1-Ultra seem to be much more area efficient than more recent Apple cores. We're at a point where Apple's E-cores are getting close to Zen or Cove cores in IPC while using just 0.6w at 2.6GHz. If you count EVERYTHING outside of the core (power, matrix co-processor, last-level-cache, share logic, etc), and average out, we get 15.555mm2 / 4 = 3.89mm2 for M1. If we do the same for Zen3 (excluding tests and infinity fabric), we have 67.85mm2 / 8 = 8.49mm2. M1 has 12mb of last-level cache (coherent) or 3mb per core while Zen3 has 4mb of coherent L1 and 32mb of victim cache (used to buffer IO/RAM read/write and to hold cache misses in hopes that they can be used eventually). You can analyze this how you would like, but M1's cache design is more efficient and gives a higher hit rate despite being smaller. Chips and Cheese has an interesting writeup of this as applied to Golden Cove. https://semianalysis.com/2022/06/10/apple-m2-die-shot-and-architecture/ https://semianalysis.com/2022/06/10/apple-m2-die-shot-and-ar... https://x.com/Locuza_/status/1538696558920736769 https://x.com/Locuza_/status/1538696558920736769 https://semianalysis.com/2022/06/17/amd-to-infinity-and-beyond/ https://semianalysis.com/2022/06/17/amd-to-infinity-and-beyo... https://chipsandcheese.com/p/going-armchair-quarterback-on-golden-coves-caches https://chipsandcheese.com/p/going-armchair-quarterback-on-g...
peterfirefly 1y ago
> and a RISC core. not actually a RISC core. µops are simpler than the externally visible instruction set but they are not RISC. (There were early x86 implementations that really were an x86 decoder bolted onto a preexisting RISC design. They didn't really perform well.) Turns out it's useful to have memory operands -- even read-modify-write operands -- in your µops. Turns out it's useful to have instructions that are wider than 32 bits. Turns out it's useful to have big literals, even if the immediate field has to be shared by a whole group of 3-4 µops (so only one of them can have a big literal). Flags are also not necessarily the problem RISC people said it was (and several RISCs actually do have flags despite the Computer Architecture 101 dogmas). Just having an reg+ofs address mode turns out to be a bad idea. Indirect addressing à la PDP-11, VAX, and 68K (and many long forgotten architectures) turned out not to be a good idea, of course.
- drob518 1y ago
  Sure, it’s not coded the same way as your external ISA does it (like you said, lots of wide information), but the core is optimized for a load/store architecture with ops that generally execute in a single pipeline stage, and the big, complex instructions in the ISA map to multiple smaller micro-ops. But yes, it is NOT literally an x86 decoder wrapped around a MIPS or ARM core.
  - peterfirefly 1y ago
    No. NOT a load/store architecture. People tried that in the 90's for x86. Doesn't work nearly as well as keeping µops generally the same as the simpler move/ALU instructions of the external ISA, just encoded differently. That's what modern x86 uses, that's what modern z/Arch ("S/360-31-64++") uses. x86 and z/Arch instructions for move/ALU/jmp/conditional branch are fine. They are not hard to decode and they are not hard to execute. That's the core of the µop instruction set (just encoded differently). Then they add some specialty stuff necessary to implement more complex instructions using sequences of µops -- and of course the SIMD stuff. That's it. It's a simpler version of the external ISA, NOT a RISC. Part of the path the µops take is wide, possibly with the option of a shared field for a large immediate. Instructions that map to short, fixed-length µops sequences are handled directly by the decoders that spit out a wide chunk of µops. Longer or variable-length µops are handled by having the decoders emit an index into a ROM of wide µops chunks. The decoders can often spit out both the first wide chunks AND the index (so there's no need to wait a cycle for the ROM to emit µops). Multi-cycle µops are not much of problem, as long as the cycle count is predictable, preferably statically predictable. It is common to have µops that are "multi-issue", for example if they involve memory operands.

rjsw 1y ago

Not for VAX, see the recent thread on it [1]. [1] https://news.ycombinator.com/item?id=45378413 https://news.ycombinator.com/item?id=45378413

drob518 1y ago
I’m not sure I get your point? Are you saying it is impossible to accelerate the VAX instruction set via the same technique used on x86? If so, you’ll have to explain why. Now, whether you’d want to or not is another question.
- p_l 1y ago
  Yes, it's not possible to do it the same way, because what made x86 successful in their application is that x86 was remarkably RISC-y in actual behaviour compared to 68k or VAX. The main reason for that is that x86 code, outside of being register poor leading to lots of stack etc. use, decomposes most "ciscy" operations into LEA (inlined in pipeline) + memory access + actual operation. VAX (and to lesser extent, m68k and others) had multiple indirections just to get the operands right, way more than what is essentially single LEA instruction. The most complex VAX instructions could have been ignored as "this is super slow one and rarely used", but the burden of handling the indirections remain, including possible huge memory latency costs.
  - clausecker 1y ago
    Also, the VAX instruction encoding is a class of horror above that of x86.
    - p_l 1y ago
      few classes above. Only ISA where I've seen a single instruction span two memory pages despite being page aligned
      - brucehoult 1y ago
        Two cache lines, sure, on earlier models, but not two VM pages!! Maximum instruction length is 56 bytes. Early models had 8 byte cache lines, later ones 64 bytes. VM page 512 bytes.
        p_l 1y ago
        I might be mistaken then, but I recall reading something about most extreme decode on VAX going into ~522 bytes. What I am more certain of was complaints about possibly ending with maaaany TLB lookups (and pagetable walks) for certain "business" optimized instructions.
        brucehoult 1y ago
        Absolutely. Six operands [1], each of which can be in a different memory page AND have an indirection via another memory page AND both the indirection and the final operand could if you're unlucky be misaligned and straddle two memory pages ... ow. [1] MOVTC (Move Translated Character), MOVTUC (Move Translated Until Character), ADDP6 (Add Packed 6-operand)
        p_l 1y ago
        I think it was implied to me that every operand of ADDP6 could have been indirected, and all the resulting 3 ranges all could straddle pages.

hajile 1y ago

Transistors aren’t free. x86 cores are all bigger than their ARM competitors even when on the same node while also getting worse performance per watt. The translation layers cost time and money to build which could be spent making the rest of the chip faster. They stuck up extra die area and use power. ARM’s total income in 2024 was half of AMDs R&D budget, but the core they finished that year can get x86 desktop levels of performance in a phone. The idea that there’s no cost to x86 just doesn’t seem to hold up under even mild scrutiny.

buildbot 1y ago
This is not really true. For example, an Apple M1 has firestorm cores that are around 3.75mm^2, and a zen3 core from around the same era is just 3mm^2 (roughly). I can make a silly 20 wide arm cpu and a silly 1 wide x86 cpu and the x86 will be smaller by a lot.
- hajile 1y ago
  Where did you get your numbers? M1 core is 2.28mm2 and Zen3 core is 4.05mm2 if you count all the core-specific stuff (and 3.09mm2 even if you exclude the power regulation and the L2 cache that only this core can use). That is 27-45% larger for generally worse performance (and all-around worse performance if per-core power is constrained to something realistic). I'd also note that Oryon and C1-Ultra seem to be much more area efficient than more recent Apple cores. We're at a point where Apple's E-cores are getting close to Zen or Cove cores in IPC while using just 0.6w at 2.6GHz. If you count EVERYTHING outside of the core (power, matrix co-processor, last-level-cache, share logic, etc), and average out, we get 15.555mm2 / 4 = 3.89mm2 for M1. If we do the same for Zen3 (excluding tests and infinity fabric), we have 67.85mm2 / 8 = 8.49mm2. M1 has 12mb of last-level cache (coherent) or 3mb per core while Zen3 has 4mb of coherent L1 and 32mb of victim cache (used to buffer IO/RAM read/write and to hold cache misses in hopes that they can be used eventually). You can analyze this how you would like, but M1's cache design is more efficient and gives a higher hit rate despite being smaller. Chips and Cheese has an interesting writeup of this as applied to Golden Cove. https://semianalysis.com/2022/06/10/apple-m2-die-shot-and-architecture/ https://semianalysis.com/2022/06/10/apple-m2-die-shot-and-ar... https://x.com/Locuza_/status/1538696558920736769 https://x.com/Locuza_/status/1538696558920736769 https://semianalysis.com/2022/06/17/amd-to-infinity-and-beyond/ https://semianalysis.com/2022/06/17/amd-to-infinity-and-beyo... https://chipsandcheese.com/p/going-armchair-quarterback-on-golden-coves-caches https://chipsandcheese.com/p/going-armchair-quarterback-on-g...

peterfirefly 1y ago

> and a RISC core. not actually a RISC core. µops are simpler than the externally visible instruction set but they are not RISC. (There were early x86 implementations that really were an x86 decoder bolted onto a preexisting RISC design. They didn't really perform well.) Turns out it's useful to have memory operands -- even read-modify-write operands -- in your µops. Turns out it's useful to have instructions that are wider than 32 bits. Turns out it's useful to have big literals, even if the immediate field has to be shared by a whole group of 3-4 µops (so only one of them can have a big literal). Flags are also not necessarily the problem RISC people said it was (and several RISCs actually do have flags despite the Computer Architecture 101 dogmas). Just having an reg+ofs address mode turns out to be a bad idea. Indirect addressing à la PDP-11, VAX, and 68K (and many long forgotten architectures) turned out not to be a good idea, of course.

drob518 1y ago
Sure, it’s not coded the same way as your external ISA does it (like you said, lots of wide information), but the core is optimized for a load/store architecture with ops that generally execute in a single pipeline stage, and the big, complex instructions in the ISA map to multiple smaller micro-ops. But yes, it is NOT literally an x86 decoder wrapped around a MIPS or ARM core.
- peterfirefly 1y ago
  No. NOT a load/store architecture. People tried that in the 90's for x86. Doesn't work nearly as well as keeping µops generally the same as the simpler move/ALU instructions of the external ISA, just encoded differently. That's what modern x86 uses, that's what modern z/Arch ("S/360-31-64++") uses. x86 and z/Arch instructions for move/ALU/jmp/conditional branch are fine. They are not hard to decode and they are not hard to execute. That's the core of the µop instruction set (just encoded differently). Then they add some specialty stuff necessary to implement more complex instructions using sequences of µops -- and of course the SIMD stuff. That's it. It's a simpler version of the external ISA, NOT a RISC. Part of the path the µops take is wide, possibly with the option of a shared field for a large immediate. Instructions that map to short, fixed-length µops sequences are handled directly by the decoders that spit out a wide chunk of µops. Longer or variable-length µops are handled by having the decoders emit an index into a ROM of wide µops chunks. The decoders can often spit out both the first wide chunks AND the index (so there's no need to wait a cycle for the ROM to emit µops). Multi-cycle µops are not much of problem, as long as the cycle count is predictable, preferably statically predictable. It is common to have µops that are "multi-issue", for example if they involve memory operands.