------- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-30 14:00 ------- (In reply to comment #5) > I will try and dig up the EABI for PowerPC, but it's not just about sticking > to > a paper. It simply does not work for me (and probably others) the way it is.
Saying that because it doesn't work for you is not really addressing the issue. The point of specifications like this are so that they create a level playing field for all to start from (and thus avoid 'arguments' as to which one is correct). Ultimately, if your code doesn't work with the prescribed model, then you have to find another way of expressing the problem. Note, I'm not trying to judge here whether your expectations of the PPC ABI are right or wrong, I'm trying to set the rational for having ABI specifications and then trying to stick to them. > I can't quite see what can be gained by minimizing access size, but not > knowing > the complete rationale (why are non-bitfields NOT minimized, e.g. volatile > int x > |= 1), how about a command line switch to let the user select? I suspect it's historical. On a machine that can do arbitrary alignment (eg, traditional CISC processors) then a common layout rule for a bit-field is to place it as close as possible to the previous field such that it all fits in one 'access' (but probably multiple memory fetches -- afterall, the memory bus is still aligned). If that access happens to be volatile, then you still don't want the memory system to be accessed twice (even transparently) and you can normally guarantee that by 'narrowing' the object. For RISC processors the alignment tends to be more critical in the normal case, so bit-fields are generally laid out with more padding. In this situation it then makes more sense to say that the bit-field's type governs the nature of the memory access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623
