4 ms·
If you disable the compressed extension then you do get enforced alignment. So, for example RV32I, RV64I both 32-bit alignment. I just ran a small linux program
by fwsgonzo 6y ago
If you disable the compressed extension then you do get enforced alignment. So, for example RV32I, RV64I both 32-bit alignment. I just ran a small linux program I had for RV32GC and I found 2 places where an instruction crossed a page border. I don't understand why they thought that was a good idea, and for such a modern architecture too, but I guess on hardware it's fine?
- monocasa 6y agoWell, there's a few places were it makes sense and doesn't. And it being an optional extension means that it pretty much exists where it's benefits outweigh it's costs. The really tiny cores with RV-C don't even have page tables, so there's no straddling to worry about. There it's very cheap, and has a lot of benefit, so you see it in the same target (and same reasons) as CortexM cores being Thumb2 based. One level of complexity up, a simple embedded core with a full MMU (taking the place of what'd be a classic 5 stage RISC like in a home router or something) is the least likely to want it, but in those cases you're normally doing buildroot like software anyway, so it's not a big deal that you have to compile everything with rv32g instead of rv32gc. Larger more powerful cores have the gate count necessary to paper over the complexity of straddling page boundaries. And that's why you see the binary distros pretty much requiring RV-C. The increased gate count there is worth the better utilization of the I$.