9 ms·

MRISC32 – An Open 32-Bit RISC/Vector ISA (Suitable for FPGA CPU)

throwaway81523 3y ago
I see like Risc-V, there are no condition flags, fine. Is there a good way to trap integer overflow and/or do multi-precision? It takes extra instructions in RISC-V which is a shortcoming.
- mbitsnbites 3y ago
  It's a shortcoming in MRISC32 too. Unlike RISC-V, MRISC32 has a madd-instruction (integer multiply+add), which is helpful in multi-precision multiplication, but there is little help in terms of carry addition arithmetic. Together with the very verbose function prologue/epilogue (explicit stores and loads from the stack, just like RISC-V, except without the "compression trick"), this is one of the main pain points of the ISA (although I don't have extensive experience with where this really matters - except obviously for 64-bit arithmetic on a 32-bit architecture, which will be less of a problem in MRISC64). I have a couple of ideas that I intend to explore in the future. One idea that I like, but that would be a slight paradigm shift for the ISA, is the "instruction decorators" that Mitch Alsup has developed for his My 66000 ISA: You can prefix a series of instructions with a "CARRY" meta-instruction, that basically tells the CPU that "for the N following instructions, propagate a carry via register Rx" (or something similar), effectively turning 2-in-1-out instructions into 3-in-2-out instructions. It's more of an encoding trick, and works with more instructions than just "ADD". The tricky parts (i.e. that modifies the architecture) would be 1) instructions can have two results, and 2) the decoration instruction adds state to the decoder that must be carried over during exceptions and similar. The latter may be possible to dodge, though, if certain restrictions are put in place (e.g. no exceptions, branches, speculation or anything similar can happen during a "decorated bunch").
peter_d_sherman 3y ago
Related: Quake on an FPGA / MRISC32: https://vimeo.com/901506667 https://vimeo.com/901506667 https://news.ycombinator.com/item?id=39029529 https://news.ycombinator.com/item?id=39029529
system2 3y ago
110MHz is not bad for quake. I remember playing with my Pentium 100 back in the day. It looked so realistic like today's RTX with some imagination.
ruslan 3y ago
Is there GCC toolchain already for this ISA ? Also, wonder how difficult would it be to add MMU to MC1 ?
- mbitsnbites 3y ago
  An MMU is somewhere on the TODO list. I'm still focusing on user space and I still have not added support for interrupts or exceptions. Exceptions in particular is something that I want to research more before I dive into implementation. So far I am of the opinion that memory faults is the only exception kind that you actually expect to see during normal program execution (IEEE-754 exceptions don't count, they are archaic and not really necessary). All other exceptions are exceptional and usually result in abnormal program termination (i.e. there's really no need to provide low latency precise exception handling for them). With that in mind, I want to investigate how to best handle memory faults, rather than just implement exceptions (although memory faults are usually handled by exceptions). There's also the issue that I want to support gather-scatter vector memory operations, which can be tricky w.r.t. memory faults (potentially a single instruction can produce one memory fault for every vector element).
- snvzz 3y ago
  >gcc There is a port. If you click on resources on the page's top bar, it yields this page[0]. 0. https://mrisc32.bitsnbites.eu/resources.html https://mrisc32.bitsnbites.eu/resources.html
  - mbitsnbites 3y ago
    Yup. Latest and greatest GCC 14: https://gitlab.com/mrisc32/mrisc32-gnu-toolchain https://gitlab.com/mrisc32/mrisc32-gnu-toolchain
snvzz 3y ago
>unfortunate design decisions >(understood as pointed at a popular RISC architecture) lack of addressing modes Politely disagree. He should provide hard evidence (hard numbers), as the authors of that ISA already did the research, and came to a different conclusion, documented in the spec.
- mbitsnbites 3y ago
  The RISC-V authors rely heavily on the argument and assumption that any high performance implementation will do instruction fusion, and the lack of indexed addressing is precisely one of the things that is expected to be fused (see page 6 in https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130...). Any implementation that does not do instruction fusion (most implementations - especially lower end ones) are out of luck, and have to pay the penalty of executing extra instructions. All modern high performance ISA:s include indexed addressing modes (most also have scaled indexed addressing). Some RISC-V implementations add these as non-standard extensions. RISC-V was not designed primarily for high performance. It targets the extremely low end (education, microcontrollers), and does it really well, and they have this clever trick (compression + instruction fusion) that makes the situation OK:ish for high end implementations. But it's not ideal. Also worth noting is that instruction fusion is far from free. It may be negligible in a really big implementation that already does things like instruction translation (uOP caches etc), but it sure feels like an unnecessary burden to bring to an ISA that hasn't even had the time to build up a legacy baggage yet. Furthermore, fused instructions often "leak" data to architectural registers (e.g. temporary registers used for address calculation), which both increases register pressure and requires that fused internal instructions must produce extra outputs (often unnecessarily). Edit: Consider the following code (https://godbolt.org/z/8YdfoT34o https://godbolt.org/z/8YdfoT34o): void store(int* array, int index, int value) { array[index] = value; } MRISC32: store(int*, int, int): stw r3, [r1, r2*4] ret RISC-V: store(int*, int, int): slli a1,a1,2 // writes to a1 add a0,a0,a1 // writes to a0 sw a2,0(a0) ret Note how the RISC-V version clobbers both the A1 and the A0 registers. Thus, a properly fused instruction would have to read from three registers and write to two register (that's bad!), whereas the MRISC32 solution only has to read three registers - no registers need to be written to (same thing for ARM and others). (You could teach the compiler to do an "add a1,a0,a1" instead so that only one register is clobbered, but that adds complexity to the compiler, and the micro architecture may not be able to rely such compiler optimizations but would most likely have to support the case with two clobbered registers anyway). Edit 2: Another main reason for not including indexed addressing modes in RISC-V is that indexed stores require three source registers (i.e. at least three register file read ports are needed) - which is a big no-no in the RISC-V philosophy. For any implementation above the purely educational level, 3+ register file read ports is the norm, but AFAIK the RISC-V authors have claimed that the base integer ISA will never require more than two source operands. I think that this philosophy weighs very heavily - more so than optimal performance.

I see like Risc-V, there are no condition flags, fine. Is there a good way to trap integer overflow and/or do multi-precision? It takes extra instructions in RISC-V which is a shortcoming.

mbitsnbites 3y ago
It's a shortcoming in MRISC32 too. Unlike RISC-V, MRISC32 has a madd-instruction (integer multiply+add), which is helpful in multi-precision multiplication, but there is little help in terms of carry addition arithmetic. Together with the very verbose function prologue/epilogue (explicit stores and loads from the stack, just like RISC-V, except without the "compression trick"), this is one of the main pain points of the ISA (although I don't have extensive experience with where this really matters - except obviously for 64-bit arithmetic on a 32-bit architecture, which will be less of a problem in MRISC64). I have a couple of ideas that I intend to explore in the future. One idea that I like, but that would be a slight paradigm shift for the ISA, is the "instruction decorators" that Mitch Alsup has developed for his My 66000 ISA: You can prefix a series of instructions with a "CARRY" meta-instruction, that basically tells the CPU that "for the N following instructions, propagate a carry via register Rx" (or something similar), effectively turning 2-in-1-out instructions into 3-in-2-out instructions. It's more of an encoding trick, and works with more instructions than just "ADD". The tricky parts (i.e. that modifies the architecture) would be 1) instructions can have two results, and 2) the decoration instruction adds state to the decoder that must be carried over during exceptions and similar. The latter may be possible to dodge, though, if certain restrictions are put in place (e.g. no exceptions, branches, speculation or anything similar can happen during a "decorated bunch").

peter_d_sherman 3y ago

Related: Quake on an FPGA / MRISC32: https://vimeo.com/901506667 https://vimeo.com/901506667 https://news.ycombinator.com/item?id=39029529 https://news.ycombinator.com/item?id=39029529

system2 3y ago

110MHz is not bad for quake. I remember playing with my Pentium 100 back in the day. It looked so realistic like today's RTX with some imagination.

ruslan 3y ago

Is there GCC toolchain already for this ISA ? Also, wonder how difficult would it be to add MMU to MC1 ?

mbitsnbites 3y ago
An MMU is somewhere on the TODO list. I'm still focusing on user space and I still have not added support for interrupts or exceptions. Exceptions in particular is something that I want to research more before I dive into implementation. So far I am of the opinion that memory faults is the only exception kind that you actually expect to see during normal program execution (IEEE-754 exceptions don't count, they are archaic and not really necessary). All other exceptions are exceptional and usually result in abnormal program termination (i.e. there's really no need to provide low latency precise exception handling for them). With that in mind, I want to investigate how to best handle memory faults, rather than just implement exceptions (although memory faults are usually handled by exceptions). There's also the issue that I want to support gather-scatter vector memory operations, which can be tricky w.r.t. memory faults (potentially a single instruction can produce one memory fault for every vector element).
snvzz 3y ago
>gcc There is a port. If you click on resources on the page's top bar, it yields this page[0]. 0. https://mrisc32.bitsnbites.eu/resources.html https://mrisc32.bitsnbites.eu/resources.html
- mbitsnbites 3y ago
  Yup. Latest and greatest GCC 14: https://gitlab.com/mrisc32/mrisc32-gnu-toolchain https://gitlab.com/mrisc32/mrisc32-gnu-toolchain

snvzz 3y ago

>unfortunate design decisions >(understood as pointed at a popular RISC architecture) lack of addressing modes Politely disagree. He should provide hard evidence (hard numbers), as the authors of that ISA already did the research, and came to a different conclusion, documented in the spec.

mbitsnbites 3y ago
The RISC-V authors rely heavily on the argument and assumption that any high performance implementation will do instruction fusion, and the lack of indexed addressing is precisely one of the things that is expected to be fused (see page 6 in https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-130...). Any implementation that does not do instruction fusion (most implementations - especially lower end ones) are out of luck, and have to pay the penalty of executing extra instructions. All modern high performance ISA:s include indexed addressing modes (most also have scaled indexed addressing). Some RISC-V implementations add these as non-standard extensions. RISC-V was not designed primarily for high performance. It targets the extremely low end (education, microcontrollers), and does it really well, and they have this clever trick (compression + instruction fusion) that makes the situation OK:ish for high end implementations. But it's not ideal. Also worth noting is that instruction fusion is far from free. It may be negligible in a really big implementation that already does things like instruction translation (uOP caches etc), but it sure feels like an unnecessary burden to bring to an ISA that hasn't even had the time to build up a legacy baggage yet. Furthermore, fused instructions often "leak" data to architectural registers (e.g. temporary registers used for address calculation), which both increases register pressure and requires that fused internal instructions must produce extra outputs (often unnecessarily). Edit: Consider the following code (https://godbolt.org/z/8YdfoT34o https://godbolt.org/z/8YdfoT34o): void store(int* array, int index, int value) { array[index] = value; } MRISC32: store(int*, int, int): stw r3, [r1, r2*4] ret RISC-V: store(int*, int, int): slli a1,a1,2 // writes to a1 add a0,a0,a1 // writes to a0 sw a2,0(a0) ret Note how the RISC-V version clobbers both the A1 and the A0 registers. Thus, a properly fused instruction would have to read from three registers and write to two register (that's bad!), whereas the MRISC32 solution only has to read three registers - no registers need to be written to (same thing for ARM and others). (You could teach the compiler to do an "add a1,a0,a1" instead so that only one register is clobbered, but that adds complexity to the compiler, and the micro architecture may not be able to rely such compiler optimizations but would most likely have to support the case with two clobbered registers anyway). Edit 2: Another main reason for not including indexed addressing modes in RISC-V is that indexed stores require three source registers (i.e. at least three register file read ports are needed) - which is a big no-no in the RISC-V philosophy. For any implementation above the purely educational level, 3+ register file read ports is the norm, but AFAIK the RISC-V authors have claimed that the base integer ISA will never require more than two source operands. I think that this philosophy weighs very heavily - more so than optimal performance.