4 ms·

Can someone please create an instruction set where the entire instruction set is implemented (even if in microcode) on every processor that uses that instructio

Can someone please create an instruction set where the entire instruction set is implemented (even if in microcode) on every processor that uses that instruction set? Have you looked at RISC-V or x64? They are messes of instruction set extensions, most of which reuse the same opcodes. We have terabytes of disk space and gigabytes of RAM. We can afford a few extra bits in the opcode.

nullc 2y ago
Is that really valuable? Stuff like clz implemented as slow emulation is arguably worse than useless because the application specific fallback can easily be faster than the emulation of the generic opcode. If the operation is slow you still have to have detection and fallback. Unless you don't care about the performance, in which case you could just never use the fancy instruction at all.
- dzaima 2y ago
  As a more modern example, pdep & pext (BMI2) on Zen 2 and Zen 3 are extremely slow, even though they're technically supported. Thus any code wanting to actually use those for anything is essentially required to add a "But actually! If I'm running on Zen 2/3, pretend pdep/pext do not exist". If you want every CPU to support every instruction without caring about perf, you could just have the OS emulate it on hitting illegal-instruction; perf isn't gonna be that different given that nothing would be using any of the potentially-slow instructions anyway and the ISA might as well not even have it in the first place. It just solves absolutely nothing to technically support everything.
  - radford-neal 2y ago
    "If you want every CPU to support every instruction..," That does indeed seem nice. As long as there's an easy way to enquire about whether an instruction is slow or not, it means that all the software runs, and the software that knows about issues with some instructions runs as fast as it would without support for those instructions. The only downside is the effort put into writing emulations of the instructions, which seems small in context.
    - brucehoult 2y ago
      There are two kinds of instructions that you might have or not have. The first is things such as vector instructions, crypto, string and blockmove which can usually be hidden away in library functions and you just set a function pointer to the correct version at program startup. But others such as ... just to pick a couple ... "ANDN" (rs1 & ~rs2) or "SH3ADD" ((rs1<<3) + rs2) are just naturally mixed in with potentially all of your code. The savings they provide relative to the base ISA make it simply not worth wrapping the in a library.
monocasa 2y ago
There's plenty that do. Pretty universally that's because they weren't interesting enough to invest in iterations. And the extensions don't really reuse opcodes. With very few exceptions the extensions aren't mutually incompatible. X86 would be a lot denser if they were.
amelius 2y ago
> We have terabytes of disk space and gigabytes of RAM. We can afford a few extra bits in the opcode. Except instructions need to be fetched, which takes time.
- hajile 2y ago
  And L1 I-cache size has what seem to be very hard limits due to complexity and latency.
imtringued 2y ago
You're basically asking for the end of backwards compatibility and every processor having a obscure unknown custom ISA that nobody can ever replicate, since you want the instruction set to be designed so that no future processor can ever be created that adds even a single new instruction to an existing instruction set. The only way that is feasible is if there is a new instruction set every time a new processor comes out. Yikes, what a dumb idea.
- colejohnson66 2y ago
  That's how things were before the IBM PC era: every computer either had an incompatible system architecture, or a wholly different CPU.
  - nickorlow 2y ago
    This would fragment compiler optimization because now instead of compiler developers (collectively) focusing on 1-3 ISAs they're split across way more.
    - 15155 2y ago
      Compiler developers lately seem focused on emitting LLVM IR.
      - nickorlow 2y ago
        Yeah, but there's still those that need to do IR -> ASM.
- mike_hearn 2y ago
  Hardly dumb. That's exactly how GPUs work. It's how mobile phones worked for a long time (J2ME). It's how Azul's old Java server worked too. Having software ship in a high level abstract form and then the hardware comes with an integrated OS/compiler combo is pretty nice from an architectural perspective. It definitely frees up the CPU designers to do things they otherwise couldn't do easily due to backwards compatibility constraints, as well as allowing new hardware features to be used immediately as long as the compiler can recognize patterns that benefit.
zik 2y ago
RISC-V has specs to suit everything from microcontrollers through high performance multi-core server level machines. It's not realistic or a good idea to use identical features for such different applications. For example a microcontroller can't be made economically with 64-bits, SIMD, quad-precision floating point, transactional memory and so on. So it makes sense to provide flexibility rather than locking in a single high-end feature set.
- brucehoult 2y ago
  Note that the $2.99 Milk-V Duo has two 64 bit CPUs, including one 1 GHz Linux capable core with MMU, FPU, and a 128 bit length-agnostic vector unit that supports 32 and 64 bit FP and 8, 16, 32, 64 bit integer. It also has 64 MB RAM. If you're talking microcontrollers at the level of the $0.10 CH32V003 then sure. https://arace.tech/products/milk-v-duo https://arace.tech/products/milk-v-duo
  - zik 2y ago
    The CV1800B in the Milk-V Duo looks very cool - but it's not an MCU. According to the product page it actually even has an auxiliary MCU in it, in addition to its two high-performance processors.
    - brucehoult 2y ago
      It's a full-featured applications processor at MCU prices. Just compare it to the $23.80 Teensy 4.0 which has 1 MB RAM (vs 64 MB) and runs a Cortex M7 at 600 MHz. That is definitely an MCU. And, when it came out, very good value for money -- I love mine. But the $3 Duo blows it away in pretty much every way. If you want to talk about just the chip, the MIMXRT1062DVL6B in the Teensy goes for $14.48 qty 1, $9.17 qty 960. https://www.digikey.com/en/products/detail/nxp-usa-inc/MIMXRT1062DVL6B/13635843 https://www.digikey.com/en/products/detail/nxp-usa-inc/MIMXR... The CV1800B goes for $18 for 5 chips, $3.60 each. https://arace.tech/products/sophon-cv1800b-5pcs https://arace.tech/products/sophon-cv1800b-5pcs "can't be made economically with 64 bits [etc]". Yeah it can.
cmrdporcupine 2y ago
The x86_64 ISA is already fragmented like this. There's a pile of different SIMD ("SSE") instruction sets, and it's pretty much anybody's guess what the system your program is running on is likely to have. cat /proc/cpuinfo sometime and just look at all the stuff under 'flags'
- neonsunset 2y ago
  RISC-V looked at that and said "Watch me, I can do even more". Also, it's a safe assumption that everyone is on x86-x64-v2 now which includes up to SSE4.2. And almost everyone is on x86-x64-v3 which includes AVX2. In practice there are about three main "bubbles" of supported extensions. Intel did try to throw a wrench into that with AVX512 but luckily AMD took a saner route and everything converges on more or less the same set of supported subsets of AVX512.
  - cmrdporcupine 2y ago
    Nah, RISC-V looked at that and decided to formalize the concept of extensions properly and put it through a proper standards process instead of letting it be dominated by the whims of manufacturer's product and marketing pipeline.
    - pclmulqdq 2y ago
      And then formalize enough of them that there are now over 1 quintillion valid ways to create a standards-conforming RISC-V core.
      - snvzz 2y ago
        Not a concern, as the common ecosystem of binary software follows RVA profiles. Microcontrollers / embedded can go wild, as the vendor controls the whole stack and can build its firmware images to suit the system.
        pclmulqdq 2y ago

nullc 2y ago

Is that really valuable? Stuff like clz implemented as slow emulation is arguably worse than useless because the application specific fallback can easily be faster than the emulation of the generic opcode. If the operation is slow you still have to have detection and fallback. Unless you don't care about the performance, in which case you could just never use the fancy instruction at all.

dzaima 2y ago
As a more modern example, pdep & pext (BMI2) on Zen 2 and Zen 3 are extremely slow, even though they're technically supported. Thus any code wanting to actually use those for anything is essentially required to add a "But actually! If I'm running on Zen 2/3, pretend pdep/pext do not exist". If you want every CPU to support every instruction without caring about perf, you could just have the OS emulate it on hitting illegal-instruction; perf isn't gonna be that different given that nothing would be using any of the potentially-slow instructions anyway and the ISA might as well not even have it in the first place. It just solves absolutely nothing to technically support everything.
- radford-neal 2y ago
  "If you want every CPU to support every instruction..," That does indeed seem nice. As long as there's an easy way to enquire about whether an instruction is slow or not, it means that all the software runs, and the software that knows about issues with some instructions runs as fast as it would without support for those instructions. The only downside is the effort put into writing emulations of the instructions, which seems small in context.
  - brucehoult 2y ago
    There are two kinds of instructions that you might have or not have. The first is things such as vector instructions, crypto, string and blockmove which can usually be hidden away in library functions and you just set a function pointer to the correct version at program startup. But others such as ... just to pick a couple ... "ANDN" (rs1 & ~rs2) or "SH3ADD" ((rs1<<3) + rs2) are just naturally mixed in with potentially all of your code. The savings they provide relative to the base ISA make it simply not worth wrapping the in a library.

monocasa 2y ago

There's plenty that do. Pretty universally that's because they weren't interesting enough to invest in iterations. And the extensions don't really reuse opcodes. With very few exceptions the extensions aren't mutually incompatible. X86 would be a lot denser if they were.

amelius 2y ago

> We have terabytes of disk space and gigabytes of RAM. We can afford a few extra bits in the opcode. Except instructions need to be fetched, which takes time.

hajile 2y ago
And L1 I-cache size has what seem to be very hard limits due to complexity and latency.

imtringued 2y ago

You're basically asking for the end of backwards compatibility and every processor having a obscure unknown custom ISA that nobody can ever replicate, since you want the instruction set to be designed so that no future processor can ever be created that adds even a single new instruction to an existing instruction set. The only way that is feasible is if there is a new instruction set every time a new processor comes out. Yikes, what a dumb idea.

colejohnson66 2y ago
That's how things were before the IBM PC era: every computer either had an incompatible system architecture, or a wholly different CPU.
- nickorlow 2y ago
  This would fragment compiler optimization because now instead of compiler developers (collectively) focusing on 1-3 ISAs they're split across way more.
  - 15155 2y ago
    Compiler developers lately seem focused on emitting LLVM IR.
    - nickorlow 2y ago
      Yeah, but there's still those that need to do IR -> ASM.
mike_hearn 2y ago
Hardly dumb. That's exactly how GPUs work. It's how mobile phones worked for a long time (J2ME). It's how Azul's old Java server worked too. Having software ship in a high level abstract form and then the hardware comes with an integrated OS/compiler combo is pretty nice from an architectural perspective. It definitely frees up the CPU designers to do things they otherwise couldn't do easily due to backwards compatibility constraints, as well as allowing new hardware features to be used immediately as long as the compiler can recognize patterns that benefit.

zik 2y ago

RISC-V has specs to suit everything from microcontrollers through high performance multi-core server level machines. It's not realistic or a good idea to use identical features for such different applications. For example a microcontroller can't be made economically with 64-bits, SIMD, quad-precision floating point, transactional memory and so on. So it makes sense to provide flexibility rather than locking in a single high-end feature set.

brucehoult 2y ago
Note that the $2.99 Milk-V Duo has two 64 bit CPUs, including one 1 GHz Linux capable core with MMU, FPU, and a 128 bit length-agnostic vector unit that supports 32 and 64 bit FP and 8, 16, 32, 64 bit integer. It also has 64 MB RAM. If you're talking microcontrollers at the level of the $0.10 CH32V003 then sure. https://arace.tech/products/milk-v-duo https://arace.tech/products/milk-v-duo
- zik 2y ago
  The CV1800B in the Milk-V Duo looks very cool - but it's not an MCU. According to the product page it actually even has an auxiliary MCU in it, in addition to its two high-performance processors.
  - brucehoult 2y ago
    It's a full-featured applications processor at MCU prices. Just compare it to the $23.80 Teensy 4.0 which has 1 MB RAM (vs 64 MB) and runs a Cortex M7 at 600 MHz. That is definitely an MCU. And, when it came out, very good value for money -- I love mine. But the $3 Duo blows it away in pretty much every way. If you want to talk about just the chip, the MIMXRT1062DVL6B in the Teensy goes for $14.48 qty 1, $9.17 qty 960. https://www.digikey.com/en/products/detail/nxp-usa-inc/MIMXRT1062DVL6B/13635843 https://www.digikey.com/en/products/detail/nxp-usa-inc/MIMXR... The CV1800B goes for $18 for 5 chips, $3.60 each. https://arace.tech/products/sophon-cv1800b-5pcs https://arace.tech/products/sophon-cv1800b-5pcs "can't be made economically with 64 bits [etc]". Yeah it can.

cmrdporcupine 2y ago

The x86_64 ISA is already fragmented like this. There's a pile of different SIMD ("SSE") instruction sets, and it's pretty much anybody's guess what the system your program is running on is likely to have. cat /proc/cpuinfo sometime and just look at all the stuff under 'flags'

neonsunset 2y ago
RISC-V looked at that and said "Watch me, I can do even more". Also, it's a safe assumption that everyone is on x86-x64-v2 now which includes up to SSE4.2. And almost everyone is on x86-x64-v3 which includes AVX2. In practice there are about three main "bubbles" of supported extensions. Intel did try to throw a wrench into that with AVX512 but luckily AMD took a saner route and everything converges on more or less the same set of supported subsets of AVX512.
- cmrdporcupine 2y ago
  Nah, RISC-V looked at that and decided to formalize the concept of extensions properly and put it through a proper standards process instead of letting it be dominated by the whims of manufacturer's product and marketing pipeline.
  - pclmulqdq 2y ago
    And then formalize enough of them that there are now over 1 quintillion valid ways to create a standards-conforming RISC-V core.
    - snvzz 2y ago
      Not a concern, as the common ecosystem of binary software follows RVA profiles. Microcontrollers / embedded can go wild, as the vendor controls the whole stack and can build its firmware images to suit the system.
      - pclmulqdq 2y ago