3 ms·

x86 is the past, but ARM is proprietary. RISC-V is the open source answer (there is SPARC but it's much older and never gained enough traction + Power/PowerPC b

x86 is the past, but ARM is proprietary. RISC-V is the open source answer (there is SPARC but it's much older and never gained enough traction + Power/PowerPC became open source too but it's also not a modern ISA)

unixgoddess 4y ago
what about AMD? wasn't it gaining traction?
- arcanemachiner 4y ago
  AMD uses x86.
  - bluGill 4y ago
    AMD had their own non-x86 instruction set once upon a time. I remember using it in the mid-90s in some embedded thing it worked, but as a developer once there is a compiler all instruction sets are hidden so I can't comment.
    - therealcamino 4y ago
      Maybe the 29000 is the one you're thinking of? https://en.m.wikipedia.org/wiki/AMD_Am29000 https://en.m.wikipedia.org/wiki/AMD_Am29000 The article says it got designed in to a bunch of laser printers, but not which ones. There were a bunch of RISC designs floating around then. The ones still relatively familiar are those that were being used as workstation CPUs -- SPARC, MIPS, POWER/PowerPC, DEC Alpha. But there were also the 29k, the Motorola 88000, and Intel i860. Probably others I'm not remembering.
- haunter 4y ago
  If you mean amd64 it's the 64 bit extension of the x86 instruction set. It's just named after AMD because they were the ones introducing it while Intel was instead working on the arguably failed brand new 64 bit-only Itanium architecture. In the end they "went back" and picked up amd64 too that's why multiple names exist: x64, x86_64, amd64.
  - unixgoddess 4y ago
    thanks, TIL
  - ghaff 4y ago
    And there were/are some differences between AMD and Intel 64-bit x86 once you get into the details (and indeed between various extensions on a given microarchitecture). x86_64 (or x86-64), ugly as it is, is probably the best way to refer to specifically 64-bit x86 at a non-vendor-specific level. Just x86 works for a lot of purposes too.
ghaff 4y ago
To be precise, RISC-V is an open architecture. (Which the hope is will be more successful than cases where the implementation was mostly take it or leave it open implementations/models.)
Steltek 4y ago
> RISC-V is the open source answer This particular CPU is not open source.
classichasclass 4y ago
What makes an ISA "modern" and why are ISAs that aren't, bad per se?
- Pet_Ant 4y ago
  They have many op codes that bloat the instruction set, that need to be broken apart to fit into a multi-scalar design. This is over head that takes of silicon space. This is especially painful with multi-core designs since each core needs this. They may have memory models that make guarantees that are insignificantly secure or impede optimisation. There is something about condition codes vs explicit checks that made speculative execution difficult. I don't recall the details about this one.
  - classichasclass 4y ago
    I don't dispute that legacy cruft is a problem, but I don't see how "not modern" (which still isn't defined) necessarily means legacy cruft. ARM or MIPS aren't especially recent in ISA terms, but I think most would agree each has less cruft in it than x86, for example.
    - brucehoult 4y ago
      Less than x86, certainly. That's a low bar. MIPS has cruft in things such as architectural load and branch delay slots. Helped in the first, simple, implementation but just (worse than) useless baggage after that. Instructions that trap on overflow too. Helped on some programs on simple implementations, but on an OoO implementation just the mere existence vastly complicates the pipeline even if programs don't use them. With Arm, the bitmapped arbitrary set of registers load/store/push/pop is cruft that helped the first simple implementations (especially ones without icache). Same with the predication on every instruction. It uses a ton of instruction encoding space, doesn't get used much outside of conditional branches, and in modern implementations branch prediction is usually so good that you don't want to predicate instructions -- certainly not several in a row. Arm is deprecating IT* predication in Thumb2 now also. Also PC as a general register is harmful to modern implementations. ANY instruction with r15 as the destination can change control flow -- load, add, xor .. whatever. At least you can tell at instruction decode time, but it needs both opcode and dst register to tell. Aarch64 fixes most of the traditional Arm cruft (everything mentioned above) and is a pretty good ISA. The main faults are that it still has condition codes (no other high performance ISA designed after 1990 does), insistence on the purity of 4-byte instructions only (Thumb2 showed that the benefit is well worth the small cost), and just the simple fact that there is TOO MUCH of it and no subsets allowed, making it impractical for small CPUs e.g. microcontrollers.

unixgoddess 4y ago

what about AMD? wasn't it gaining traction?

arcanemachiner 4y ago
AMD uses x86.
- bluGill 4y ago
  AMD had their own non-x86 instruction set once upon a time. I remember using it in the mid-90s in some embedded thing it worked, but as a developer once there is a compiler all instruction sets are hidden so I can't comment.
  - therealcamino 4y ago
    Maybe the 29000 is the one you're thinking of? https://en.m.wikipedia.org/wiki/AMD_Am29000 https://en.m.wikipedia.org/wiki/AMD_Am29000 The article says it got designed in to a bunch of laser printers, but not which ones. There were a bunch of RISC designs floating around then. The ones still relatively familiar are those that were being used as workstation CPUs -- SPARC, MIPS, POWER/PowerPC, DEC Alpha. But there were also the 29k, the Motorola 88000, and Intel i860. Probably others I'm not remembering.
haunter 4y ago
If you mean amd64 it's the 64 bit extension of the x86 instruction set. It's just named after AMD because they were the ones introducing it while Intel was instead working on the arguably failed brand new 64 bit-only Itanium architecture. In the end they "went back" and picked up amd64 too that's why multiple names exist: x64, x86_64, amd64.
- unixgoddess 4y ago
  thanks, TIL
- ghaff 4y ago
  And there were/are some differences between AMD and Intel 64-bit x86 once you get into the details (and indeed between various extensions on a given microarchitecture). x86_64 (or x86-64), ugly as it is, is probably the best way to refer to specifically 64-bit x86 at a non-vendor-specific level. Just x86 works for a lot of purposes too.

ghaff 4y ago

To be precise, RISC-V is an open architecture. (Which the hope is will be more successful than cases where the implementation was mostly take it or leave it open implementations/models.)

Steltek 4y ago

> RISC-V is the open source answer This particular CPU is not open source.

classichasclass 4y ago

What makes an ISA "modern" and why are ISAs that aren't, bad per se?

Pet_Ant 4y ago
They have many op codes that bloat the instruction set, that need to be broken apart to fit into a multi-scalar design. This is over head that takes of silicon space. This is especially painful with multi-core designs since each core needs this. They may have memory models that make guarantees that are insignificantly secure or impede optimisation. There is something about condition codes vs explicit checks that made speculative execution difficult. I don't recall the details about this one.
- classichasclass 4y ago
  I don't dispute that legacy cruft is a problem, but I don't see how "not modern" (which still isn't defined) necessarily means legacy cruft. ARM or MIPS aren't especially recent in ISA terms, but I think most would agree each has less cruft in it than x86, for example.
  - brucehoult 4y ago
    Less than x86, certainly. That's a low bar. MIPS has cruft in things such as architectural load and branch delay slots. Helped in the first, simple, implementation but just (worse than) useless baggage after that. Instructions that trap on overflow too. Helped on some programs on simple implementations, but on an OoO implementation just the mere existence vastly complicates the pipeline even if programs don't use them. With Arm, the bitmapped arbitrary set of registers load/store/push/pop is cruft that helped the first simple implementations (especially ones without icache). Same with the predication on every instruction. It uses a ton of instruction encoding space, doesn't get used much outside of conditional branches, and in modern implementations branch prediction is usually so good that you don't want to predicate instructions -- certainly not several in a row. Arm is deprecating IT* predication in Thumb2 now also. Also PC as a general register is harmful to modern implementations. ANY instruction with r15 as the destination can change control flow -- load, add, xor .. whatever. At least you can tell at instruction decode time, but it needs both opcode and dst register to tell. Aarch64 fixes most of the traditional Arm cruft (everything mentioned above) and is a pretty good ISA. The main faults are that it still has condition codes (no other high performance ISA designed after 1990 does), insistence on the purity of 4-byte instructions only (Thumb2 showed that the benefit is well worth the small cost), and just the simple fact that there is TOO MUCH of it and no subsets allowed, making it impractical for small CPUs e.g. microcontrollers.