Hacker News new | ask | show | jobs
by sbanach 4537 days ago
So arm compilers must prefer to, for example, XOR with 0x10000000 rather than AND with 0xEFFFFFFF?
2 comments

AND 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.
And if you need something like ~(byte << N) for any purpose there's still MVN (move-not).

     MVN r0, #0x10000000 ; ro = 0xefffffff
Oh, the joy :-).
CMN 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.
Aside 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.
Wouldn't that require the pc-relative address to fit into this immediate scheme?
In 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.
That'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.