5 ms·

> Personally, I have more faith in a third alternative: a virtual instruction set. Like bytecode, though not managed like Java, and not meant to be interpreted

by danjayh 11y ago

> Personally, I have more faith in a third alternative: a virtual instruction set. Like bytecode, though not managed like Java, and not meant to be interpreted or JIT compiled either. It could run on the bare metal, or be translated into something that is —like the Mill CPU. That way you can keep the illusion of having a single instruction set, while sacrificing virtually nothing. Moreover, future CPUs don't even need backward compatibility, as long as you can translate (and optimise!) the virtual assembly for them. I don't think he really gets how CPUs work -- it's already that way, and has been for quite a while. The published instruction sets are the 'virtual' instructions, and translation of these instructions (be they ARM, x86, or PowerPC) is baked into each CPU's microcode. We actually have no visibility into the 'real' instructions that CPUs execute ('micro-ops'), because they're proprietary.

loup-vaillant 11y ago
The idea is to own up to this reality, and stop designing instruction sets as if they were meant run directly. x86 in particular has a legacy of simple CPUs that didn't have much of a decoding unit. But now it has gone too far in the other direction: it takes a significant amount of chip surface and energy to decode, making it unsuitable for low power situations. ARM on the other hand is probably lacking in the SIMD department (I haven't checked). We need to go back and overhaul the CPU instruction set like Vulkan, Dx12 and Mantle overhauled the GPU APIs. We need to reflect on what CPUs can do, what they can do fast, and what they can do with low power. Then we need an instruction set that would act as an API to these subsystems. Something orthogonal, that doesn't take too much energy to decode, and could be decoded in parallel if need be (for crazy desktop speed ups). While we're at it, it might be nice to have explicit support for things like pointer tags, to speed up dynamic stuff like garbage collection and runtime type information. You're right, I don't really get how CPUs work. But I did pick up a few things that lead me to trust instruction set design is not over. We can do better.
- loup-vaillant 11y ago
  When I make a long comment, I like to see explanations about what warranted a downvote. So I can learn…
  - danjayh 11y ago
    I didn't personally downvote you, but I'll give you my best guesses: 1) The percentage of die used for decoding is actually already quite low. Per Anandtech 2014, it was at 10% for x86 and decreasing: http://www.anandtech.com/show/8776/arm-challinging-intel-in-the-server-market-an-overview/12 http://www.anandtech.com/show/8776/arm-challinging-intel-in-... Since there is a floor to the number of transistors needed for decoding, there might not be a whole lot to gain there. 2) Progress has already been made towards updating instruction sets to reflect what CPUs do quickly, well etc. It started with MMX back in the stone age, and has progressed through a plethora of SIMD and media acceleration instructions. 3) Instruction sets are already not designed as if they were supposed to be run directly. Quite to the contrary, they are abstracted -- the instruction set is the API, and the microoperations are the instructions. Designing them as if they were to run directly would mean exposing the micro-ops, which would require backwards compatibility breaking changes to the CPU each generation when there were changes to the micro ops. 4) The current system already pretty well levels energy consumption between competing ISAs. See: http://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient http://www.extremetech.com/extreme/188396-the-final-isa-show... You're describing something that sounds like a bytecode VM, but in essence, that's what modern processors already are. Unfortunately, x86 (at least 32 bit) assembly is pretty unpleasant as an 'API', but ARM and PowerPC are both pretty good. As far as pointer tagging, that's something that's probably mostly limited by memory bandwidth (it's not a particularly compute heavy thing to do), so unless the HW support came in the form of a dedicated on-chip cache, it probably wouldn't get you very much ... and then, if you're going to the expense of adding a dedicated on-chip cache, it's probably going to be more effective as a general purpose cache -- if the code is accessing the pointer metadata often, it will be in cache, and therefore accelerated. Not trying to rain on your parade, I like seeing creative ideas, and I have no idea why people are downvoting you. Have an upvote on me :). EDIT: Also, ARM has NEON.
    - loup-vaillant 11y ago
      Whoa, I was hopelessly out of date. Thanks.

by danjayh 11y ago

loup-vaillant 11y ago

The idea is to own up to this reality, and stop designing instruction sets as if they were meant run directly. x86 in particular has a legacy of simple CPUs that didn't have much of a decoding unit. But now it has gone too far in the other direction: it takes a significant amount of chip surface and energy to decode, making it unsuitable for low power situations. ARM on the other hand is probably lacking in the SIMD department (I haven't checked). We need to go back and overhaul the CPU instruction set like Vulkan, Dx12 and Mantle overhauled the GPU APIs. We need to reflect on what CPUs can do, what they can do fast, and what they can do with low power. Then we need an instruction set that would act as an API to these subsystems. Something orthogonal, that doesn't take too much energy to decode, and could be decoded in parallel if need be (for crazy desktop speed ups). While we're at it, it might be nice to have explicit support for things like pointer tags, to speed up dynamic stuff like garbage collection and runtime type information. You're right, I don't really get how CPUs work. But I did pick up a few things that lead me to trust instruction set design is not over. We can do better.

loup-vaillant 11y ago
When I make a long comment, I like to see explanations about what warranted a downvote. So I can learn…
- danjayh 11y ago
  I didn't personally downvote you, but I'll give you my best guesses: 1) The percentage of die used for decoding is actually already quite low. Per Anandtech 2014, it was at 10% for x86 and decreasing: http://www.anandtech.com/show/8776/arm-challinging-intel-in-the-server-market-an-overview/12 http://www.anandtech.com/show/8776/arm-challinging-intel-in-... Since there is a floor to the number of transistors needed for decoding, there might not be a whole lot to gain there. 2) Progress has already been made towards updating instruction sets to reflect what CPUs do quickly, well etc. It started with MMX back in the stone age, and has progressed through a plethora of SIMD and media acceleration instructions. 3) Instruction sets are already not designed as if they were supposed to be run directly. Quite to the contrary, they are abstracted -- the instruction set is the API, and the microoperations are the instructions. Designing them as if they were to run directly would mean exposing the micro-ops, which would require backwards compatibility breaking changes to the CPU each generation when there were changes to the micro ops. 4) The current system already pretty well levels energy consumption between competing ISAs. See: http://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient http://www.extremetech.com/extreme/188396-the-final-isa-show... You're describing something that sounds like a bytecode VM, but in essence, that's what modern processors already are. Unfortunately, x86 (at least 32 bit) assembly is pretty unpleasant as an 'API', but ARM and PowerPC are both pretty good. As far as pointer tagging, that's something that's probably mostly limited by memory bandwidth (it's not a particularly compute heavy thing to do), so unless the HW support came in the form of a dedicated on-chip cache, it probably wouldn't get you very much ... and then, if you're going to the expense of adding a dedicated on-chip cache, it's probably going to be more effective as a general purpose cache -- if the code is accessing the pointer metadata often, it will be in cache, and therefore accelerated. Not trying to rain on your parade, I like seeing creative ideas, and I have no idea why people are downvoting you. Have an upvote on me :). EDIT: Also, ARM has NEON.
  - loup-vaillant 11y ago
    Whoa, I was hopelessly out of date. Thanks.