4 ms·

I wonder how easy it would be to port https://github.com/xoreaxeaxeax/sandsifter https://github.com/xoreaxeaxeax/sandsifter to the RISC-V instruction set. Woul

I wonder how easy it would be to port https://github.com/xoreaxeaxeax/sandsifter https://github.com/xoreaxeaxeax/sandsifter to the RISC-V instruction set. Would probably be a decent step in the right direction for validating/verifying the future of trusted computing. Although... this gives rise to a 2nd thought. If it was _this easy_ to build a RISC-V implementation, is it all that special, technically speaking? I ask as someone naive about processor design. Is implementation relatively straightforward, but design hard?

_chris_ 8y ago
RISC-V is pretty nice in that the ISA gets out of your way, and you can focus on the techniques to build a high-performance processor without wasting effort on legacy and other weird corner case behaviors. A++, would recommend. However, if you want to build really high performance cores, there are plenty of challenging techniques you have to employ that add a lot of complexity that is hidden below the ISA abstraction layer (speculation for example). So if you want to make RISC-V go fast, you have to employ more design tricks like "macro-op fusion". For example, scan for two load instructions in the fetch stream and fuse them into a single "load-pair" micro-op if they access adjacent addresses. There are a whole bag of tricks like this that are irrespective of the ISA and add a fairly high "skill-ceiling" to processor design.
- renox 8y ago
  > RISC-V is pretty nice in that the ISA gets out of your way Except for the C variant where they went to 110% complexity for maximum ICache efficiency: 32bit instructions aligned to 16bit?? I wonder if there are other RISC ISA which made the same choice.
  - phkahler 8y ago
    Yes, while the C extension helps for high performance I think it feels like a major hack to instruction encoding. The RISC-V ISA does great with a very small number of instructions, so playing around with encodings is rather easy. I'm reaching the conclusion that fixed 24-bit opcodes are an close to optimal if immediate constants are allowed after.
leibwiht 8y ago
My understanding of sandsifter is that it works by executing an instruction next to a page boundary, which gives either a page fault error (the instruction executed correctly and then execution passed over to the next page which is presumably non-executable) or an error indicating the instruction was malformed. So, for it to work on RISC-V you need paging, and also interrupt vectors to work. The MMU was only recently standardized so I'm not sure if it's actually implemented in any hardware or software yet, but once you have those two things it should be fairly straightforward.
- _chris_ 8y ago
  Sandsifter is dealing with the problem of "how do I find valid instructions in any 1-15 byte sequence, which yields 2^120 combinations?" In RISC-V there are currently only 2 byte and 4 byte instructions, which you can brute force your way through. The specification does technically allow for longer sequences, in which case sandsifter will work just fine. [And the RISC-v privileged specification has existed for years].
  - leibwiht 8y ago
    >And the RISC-v privileged specification has existed for years It is a draft which has not been finalized and contains a disclaimer that it might be modified in a non-backwards compatible way prior to final release.
- cmrx64 8y ago
  > The MMU was only recently standardized so I'm not sure if it's actually implemented in any hardware or software yet, but once you have those two things it should be fairly straightforward Chips with MMUs have been taped out for years. Likewise the Linux port has existed for years.
brandmeyer 8y ago
Take a good look at this deep dive on the Samsung M3 core. Its an ARMv8 processor, which is a fairly orthodox RISC in its capabilities. A RISC-V processor of similar capabilities would have a similar structure. The ISA simply doesn't help all that much at the very high-end. https://www.anandtech.com/show/13199/hot-chips-2018-samsungs-exynosm3-cpu-architecture-deep-dive https://www.anandtech.com/show/13199/hot-chips-2018-samsungs... The advantage of working with RISC-V over ARM right now is that you can configure a RV core to have far less capability than an ARM core. You can license RTL from SiFive for RV64imc (64-bit address and data, baseline integer instruction set, hardware multiply, and 16-bit compressed instructions). Such a core simply does not exist in the ARM marketplace today, partially because NEON is mandatory in ARMv8.
gchadwick 8y ago
It's not too hard to build a basic processor that can execute enough of an ISA to do something 'real' such as boot Linux, especially if you can craft the kernel build to keep it as simple as possible. First the complexity comes in fully implementing the whole ISA. Yes RISC-V has an advantage over ARM/x86 in that it will have less cruft, but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real software requirements so RISC-V will need similar complexity if it wants to seriously challenge either architecture (with the advantage they can learn from the previous mistakes made and thus implement things more cleanly). Second it comes in verifying your design, especially around the fun corner cases. There are plenty of bugs that occur when a series of rare things happens at once (maybe involving some obscure areas of the ISA) which can be very hard to track down. Unless you can successfully hunt down and fix these you'll end up with a phone or a computer that occasionally crashes for no good reason. Third is making it hit your power and performance targets. It's one thing to say you have a 256-bit data path and can issue 4 instructions per cycle with out of order execution. It's quite another to build such a design so it can actually sustain decent throughput on real software whilst hitting a decent clock frequency and remaining within power budget, especially when you have all of the various complex bits of ISA to deal with.
- nickik 8y ago
  > but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real software requirements so RISC-V will need similar complexity if it wants to seriously challenge either architecture Like what? Are you talking about extensions that don't exist for RISC-V, like Transnational Memory? I would say most reason for complexity is legacy and there is little actual software requirements in that regard if your doing a new architecture.
  - gchadwick 8y ago
    I'm more talking about common things. Take the humble load, give a memory address, get some data into a register, what could be simpler? Well for one thing your load may come in multiple sizes, can target different kinds of memory (e.g. device memory, non-cacheable memory, fully-cached memory, ARM architecture actually allows you to get quite specific about differing levels or shareability and cacheability too), can be unaligned with respect to the access size (but you still need full performance with them). There are ordering requirements with respect to other loads and stores in the system (even within the same CPU avoiding read-after-read ordering issues may not be simple) and various different kinds of barriers that can effect loads. You get exclusive loads or atomics (some variations can return the data seen so are performing a load on top the atomic op). It may be a vector load that needs to quickly feed the vector register file as opposed to the 'standard' register file. In a multi-processor system you can have various different types of snoop operation coming in that could effect the load. You also need to work out if you're actually allowed to do that load, modern page tables are pretty complex affairs. The page table itself could be changing as the load is executing. A decent chunk of the complexity is for virtualisation support but even without that there's various fiddly bits. You also have speculative execution attacks to worry about. Certain loads may need to be very sure they should execute before doing anything, others may be free to speculate away and forward data into further speculative execution. You can certainly build a perfectly functional ISA that avoids a lot of this (and avoid other things by keeping to a simple in-order microarchitecture) but that will loose you a lot of performance.

_chris_ 8y ago

RISC-V is pretty nice in that the ISA gets out of your way, and you can focus on the techniques to build a high-performance processor without wasting effort on legacy and other weird corner case behaviors. A++, would recommend. However, if you want to build really high performance cores, there are plenty of challenging techniques you have to employ that add a lot of complexity that is hidden below the ISA abstraction layer (speculation for example). So if you want to make RISC-V go fast, you have to employ more design tricks like "macro-op fusion". For example, scan for two load instructions in the fetch stream and fuse them into a single "load-pair" micro-op if they access adjacent addresses. There are a whole bag of tricks like this that are irrespective of the ISA and add a fairly high "skill-ceiling" to processor design.

renox 8y ago
> RISC-V is pretty nice in that the ISA gets out of your way Except for the C variant where they went to 110% complexity for maximum ICache efficiency: 32bit instructions aligned to 16bit?? I wonder if there are other RISC ISA which made the same choice.
- phkahler 8y ago
  Yes, while the C extension helps for high performance I think it feels like a major hack to instruction encoding. The RISC-V ISA does great with a very small number of instructions, so playing around with encodings is rather easy. I'm reaching the conclusion that fixed 24-bit opcodes are an close to optimal if immediate constants are allowed after.

leibwiht 8y ago

My understanding of sandsifter is that it works by executing an instruction next to a page boundary, which gives either a page fault error (the instruction executed correctly and then execution passed over to the next page which is presumably non-executable) or an error indicating the instruction was malformed. So, for it to work on RISC-V you need paging, and also interrupt vectors to work. The MMU was only recently standardized so I'm not sure if it's actually implemented in any hardware or software yet, but once you have those two things it should be fairly straightforward.

_chris_ 8y ago
Sandsifter is dealing with the problem of "how do I find valid instructions in any 1-15 byte sequence, which yields 2^120 combinations?" In RISC-V there are currently only 2 byte and 4 byte instructions, which you can brute force your way through. The specification does technically allow for longer sequences, in which case sandsifter will work just fine. [And the RISC-v privileged specification has existed for years].
- leibwiht 8y ago
  >And the RISC-v privileged specification has existed for years It is a draft which has not been finalized and contains a disclaimer that it might be modified in a non-backwards compatible way prior to final release.
cmrx64 8y ago
> The MMU was only recently standardized so I'm not sure if it's actually implemented in any hardware or software yet, but once you have those two things it should be fairly straightforward Chips with MMUs have been taped out for years. Likewise the Linux port has existed for years.

brandmeyer 8y ago

Take a good look at this deep dive on the Samsung M3 core. Its an ARMv8 processor, which is a fairly orthodox RISC in its capabilities. A RISC-V processor of similar capabilities would have a similar structure. The ISA simply doesn't help all that much at the very high-end. https://www.anandtech.com/show/13199/hot-chips-2018-samsungs-exynosm3-cpu-architecture-deep-dive https://www.anandtech.com/show/13199/hot-chips-2018-samsungs... The advantage of working with RISC-V over ARM right now is that you can configure a RV core to have far less capability than an ARM core. You can license RTL from SiFive for RV64imc (64-bit address and data, baseline integer instruction set, hardware multiply, and 16-bit compressed instructions). Such a core simply does not exist in the ARM marketplace today, partially because NEON is mandatory in ARMv8.

gchadwick 8y ago

It's not too hard to build a basic processor that can execute enough of an ISA to do something 'real' such as boot Linux, especially if you can craft the kernel build to keep it as simple as possible. First the complexity comes in fully implementing the whole ISA. Yes RISC-V has an advantage over ARM/x86 in that it will have less cruft, but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real software requirements so RISC-V will need similar complexity if it wants to seriously challenge either architecture (with the advantage they can learn from the previous mistakes made and thus implement things more cleanly). Second it comes in verifying your design, especially around the fun corner cases. There are plenty of bugs that occur when a series of rare things happens at once (maybe involving some obscure areas of the ISA) which can be very hard to track down. Unless you can successfully hunt down and fix these you'll end up with a phone or a computer that occasionally crashes for no good reason. Third is making it hit your power and performance targets. It's one thing to say you have a 256-bit data path and can issue 4 instructions per cycle with out of order execution. It's quite another to build such a design so it can actually sustain decent throughput on real software whilst hitting a decent clock frequency and remaining within power budget, especially when you have all of the various complex bits of ISA to deal with.

nickik 8y ago
> but the complexity in ARM/x86 doesn't exist for no reason. It's driven by real software requirements so RISC-V will need similar complexity if it wants to seriously challenge either architecture Like what? Are you talking about extensions that don't exist for RISC-V, like Transnational Memory? I would say most reason for complexity is legacy and there is little actual software requirements in that regard if your doing a new architecture.
- gchadwick 8y ago
  I'm more talking about common things. Take the humble load, give a memory address, get some data into a register, what could be simpler? Well for one thing your load may come in multiple sizes, can target different kinds of memory (e.g. device memory, non-cacheable memory, fully-cached memory, ARM architecture actually allows you to get quite specific about differing levels or shareability and cacheability too), can be unaligned with respect to the access size (but you still need full performance with them). There are ordering requirements with respect to other loads and stores in the system (even within the same CPU avoiding read-after-read ordering issues may not be simple) and various different kinds of barriers that can effect loads. You get exclusive loads or atomics (some variations can return the data seen so are performing a load on top the atomic op). It may be a vector load that needs to quickly feed the vector register file as opposed to the 'standard' register file. In a multi-processor system you can have various different types of snoop operation coming in that could effect the load. You also need to work out if you're actually allowed to do that load, modern page tables are pretty complex affairs. The page table itself could be changing as the load is executing. A decent chunk of the complexity is for virtualisation support but even without that there's various fiddly bits. You also have speculative execution attacks to worry about. Certain loads may need to be very sure they should execute before doing anything, others may be free to speculate away and forward data into further speculative execution. You can certainly build a perfectly functional ISA that avoids a lot of this (and avoid other things by keeping to a simple in-order microarchitecture) but that will loose you a lot of performance.