5 ms·
So arm compilers must prefer to, for example, XOR with 0x10000000 rather than AND with 0xEFFFFFFF?
by sbanach 13y ago
So arm compilers must prefer to, for example, XOR with 0x10000000 rather than AND with 0xEFFFFFFF?
- stephencanon 13y agoAND with 0xefffffff would become BIC ("bit clear", aka "and not") with 0x10000000. But yes, the basic idea of your comment is correct. Fortunately, compilers are quite good at this sort of thing.
- cnvogel 13y agoAnd if you need something like ~(byte << N) for any purpose there's still MVN (move-not). MVN r0, #0x10000000 ; ro = 0xefffffff Oh, the joy :-).
- stephencanon 13y agoCMN is the real gem. It's an endless source of bugs in the time between when compiler writers discover it and when they figure out how it actually sets flags. ARM would have done well to provide a "here's how you actually use this instruction" guide in the architecture reference manual.
- asveikau 13y agoAside from this kind of trick, I have not worked with a ton of ARM assembly but what I find is very frequently compilers will just put values in the text section close to where they are used and refer to them with some PC-relative thing, rather than using immediate values as often as they might on x86. I have seen this on other RISC platforms as well.
- thrownaway2424 13y agoWouldn't that require the pc-relative address to fit into this immediate scheme?
- stephencanon 13y agoIn order to have a single-instruction PR-relative load the offset needs to be small (though it uses a different immediate scheme for the offset). So in practice you usually tuck small constant islands between blocks of executable code when you adopt this approach.
- thrownaway2424 13y agoThat's what I was thinking. I also started wondering how a large structure might be packed, when you can relatively address every byte in the nearest 256 bytes but only every 4 bytes in the next KB and so on. It could sort of upend the way you might normally think about packing a struct.