Not traditional VLIW per-se as packets wouldn't imply parallelism (though that's theoretically possible) and instruction count would vary.
2-register to 3-register also just involves different wiring and costs nothing. I think you'd see 15-bit stick with 2-register. 20-bit would more interesting. You could choose to spend 3 bits on a third register or you could widen 2-register instructions to access the 32 core registers (or something between where you do 3-register, but only on 16 registers). 20-bit also reduces some of the need for very large 15-bit immediates (especially jump which is upward of 10% of the total space on 32-bit designs) which could allow more 15-bit instructions further improving effective density.
Easy access to 40/60-bit instructions mean stuff like vsetvli could simply go away and very useful instructions like FMA4 (instead of FMA3) could be added. Vector masking is another big one. They don't have enough bytes for a full vector mask set resulting in some hacks.
The big question is about jumping and predicting inside packets. You can add 2 bits for what externally looks like 16-bit addressing (where the 2 bits indicate packet position to jump to) or have faster jumps that always hit the beginning of the packet (at the expense of code density due to nops). There might even be a hybrid approach where short jumps can jump within a packed, but long jumps must jump to packet boundaries (which makes sense as most compilers make functions align on cache line boundaries anyway). There is a point for eliminating 20-bit (and all that compression goodness) for 45+15-bit pairs instead) as branches inside packets are immediately calculable.
One thing I noticed with your clever encoding is that you can avoid some nops: instead of having 2 15 bits instructions followed by two nops, you could have two 30 bits instructions, saving maybe a little decoding energy.
Also the 60bit format will really help for loading immediates..
That said I wonder why normal ISA do not contain a 'Load Immediate on Next PC'?
And if you want to allow parallel decoding the first byte of the immediate would be a 'special noop' and the first immediate byte would be inside the Load Immediate Next PC instruction instead.
I think this has to do with parallel decoding. How do you tell that the immediate is an immediate instead of an instruction? You have to carve out a very large part of the encoding space and you still can't fit a full immediate (eg, if you decided that all instructions starting with 1 were immediates, you'd be dedicating half of your encoding space to immediates and still be one bit short).
RISC-V does a 20-bit LUI (load upper immediate) then a 12-bit addi to the same register for the lower bits. Having access to 40-60 bit immediates makes 32-bit immediates a lot easier (with 64-bit immediates being multi-step, but quite uncommon).
Not traditional VLIW per-se as packets wouldn't imply parallelism (though that's theoretically possible) and instruction count would vary.
2-register to 3-register also just involves different wiring and costs nothing. I think you'd see 15-bit stick with 2-register. 20-bit would more interesting. You could choose to spend 3 bits on a third register or you could widen 2-register instructions to access the 32 core registers (or something between where you do 3-register, but only on 16 registers). 20-bit also reduces some of the need for very large 15-bit immediates (especially jump which is upward of 10% of the total space on 32-bit designs) which could allow more 15-bit instructions further improving effective density.
Easy access to 40/60-bit instructions mean stuff like vsetvli could simply go away and very useful instructions like FMA4 (instead of FMA3) could be added. Vector masking is another big one. They don't have enough bytes for a full vector mask set resulting in some hacks.
The big question is about jumping and predicting inside packets. You can add 2 bits for what externally looks like 16-bit addressing (where the 2 bits indicate packet position to jump to) or have faster jumps that always hit the beginning of the packet (at the expense of code density due to nops). There might even be a hybrid approach where short jumps can jump within a packed, but long jumps must jump to packet boundaries (which makes sense as most compilers make functions align on cache line boundaries anyway). There is a point for eliminating 20-bit (and all that compression goodness) for 45+15-bit pairs instead) as branches inside packets are immediately calculable.
One thing I noticed with your clever encoding is that you can avoid some nops: instead of having 2 15 bits instructions followed by two nops, you could have two 30 bits instructions, saving maybe a little decoding energy.
Also the 60bit format will really help for loading immediates..
That said I wonder why normal ISA do not contain a 'Load Immediate on Next PC'? And if you want to allow parallel decoding the first byte of the immediate would be a 'special noop' and the first immediate byte would be inside the Load Immediate Next PC instruction instead.
I think this has to do with parallel decoding. How do you tell that the immediate is an immediate instead of an instruction? You have to carve out a very large part of the encoding space and you still can't fit a full immediate (eg, if you decided that all instructions starting with 1 were immediates, you'd be dedicating half of your encoding space to immediates and still be one bit short).
RISC-V does a 20-bit LUI (load upper immediate) then a 12-bit addi to the same register for the lower bits. Having access to 40-60 bit immediates makes 32-bit immediates a lot easier (with 64-bit immediates being multi-step, but quite uncommon).