Yann Guidon / YGDESWhat should be the size of an instruction ?
Well, it depends... of course !
Usually, this is a constraint from the very beginning. But the beginning is the moment when nothing is quite sure so the chances are high to get it wrong. However it's one of the most determining features of a core.
In my experiments, I have found that the average ideal instruction width is around 24 bits. Which is not handy at all. This is what I chose for the #YGREC-РЭС15-bis because Harvard makes it still convenient (the ADSP21xx line uses 24 bits too for a 16-bits datapath). But this is an exception...
#YGREC8 has 16 bits per instruction. It's very tight (there can be only 2 register addresses) but still works for a 8 bits datapath.
"compact" instructions sets (like ARM Thumb) also favor 16 bits but this also increases the instruction count so the code size does not decrease by a factor of 2 compared to a plain 32 bits processor.
#YASEP Yet Another Small Embedded Processor uses a variable size instruction, either 16 or 32 bits (with one prefix bit). It's a good compromise but might be tricky if the architecture is extended beyond its intended target.
RISC-V manages to use 30 out of 32 bits. It's nice but the proposed extensions are crazy weird...
Most RISC processors use 32 bits.
Anyway it's pretty clear that variable-sized instruction sets must be avoided (the case of the YASEP is a bit special).
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
I would advise that while there are complexities with respect to Variable Length Instruction Width Instruction sets there are a few advantages.
1. Memory Density is improved, especially if you use the compressed instructions.
2. In designs which contain caches the effect is magnified.
3. I think if you ensure that the increments are 8 bit increments life will be a lot easier.
But I agree a fixed length is a lot easier :).
Are you sure? yes | no
VarLIWI density advantage is not really easy to quantify. Compressed instructions are shorter, but code sequences might be 30% shorter and 30% Slower (we'll need to find real data). Decoding might take several cycles and prevent or complicate superscalar implementations.
I'd rather have small instructions that are simple and atomic, which can be "assembled" as strings/sequences that perform more complex operations and are easy to decode as packs :-)
Are you sure? yes | no
RISC-V extensions crazy? It has historical precedent; the IBM System/360 mainframe architecture uses the top 2 bits of its primary opcode byte to indicate to the fetch logic how many subsequent bytes to fetch for the full instruction. Length-encoded instructions have appeared elsewhere in history as well.
As far as weird goes, I fail to understand what makes the current set of extensions weird. The most bizarre mapping is the RV128 register load instructions, and that's only because they ran out of available opcode space in the existing allotments for loads. Everything else is pretty bone stock standard.
Are you sure? yes | no