3 ms·
There is also a middle ground of requiring to pad 16/48-bit sequences with 16-bit NOP to align them to 32 bits. I agree that at this time it's not clear whether
by newpavlov 2y ago
There is also a middle ground of requiring to pad 16/48-bit sequences with 16-bit NOP to align them to 32 bits. I agree that at this time it's not clear whether the C extension is a good idea or not (same with the V extension).
- sweetjuly 2y agoThe C extension authors did consider requiring alignment/padding to prevent the misaligned 32-bit instruction issues, but they specifically mention rejecting it since it ate up all the code size savings.
- Dylan16807 2y agoDid they specifically analyze doing alignment on a cache line basis?
- adgjlsfhk1 2y agothat seems really tough for compilers.
- dmitrygr 2y agoNot really. Most modern x86 compilers already align jump targets to cache line boundaries since this helps x86 a lot. So it is doable. If you compile each function into a section (common), then the linker can be told to align them to 64 or 128 bytes easily. Code size would grow (but tetris can be played to reduce this by packing functions)
- sweetjuly 2y agoThis would require specifying a cache line size in the ABI, which is a somewhat odd uarch detail to bubble up. While 64-bytes is conventional for large application processors and has been for a long time, I wouldn't want to make it a requirement.
- Dylan16807 2y agoIt's definitely worth analyzing though. See how big of a block you need to get 90% of the compression benefit, etc.