> > I never said you should keep native layout structures. I merely said > > that it leads to better code if the data is converted to CPU endianness > > at the system boundary. While the actual system boundary is obviously > > the PCI(-E) bus, the logical system boundary may well be at the point > > where you load a certain value from the DMA memory into the CPU to > > operate with it (whether it's then pushed back out to memory on the > > stack is uninteresting). > > I'm not buying this logical boundary definition if you don't do clean > cut you still have to be endian aware across the whole code so what's > a difference. No, you only have to be endian aware when you do a load from a structure you *know* was/is DMAed from/to the card. That's a world of a difference. > Yes, doing that can lead to larger C files, but > > the compile result won't suffer; given a sufficiently smart compiler > > it'll even be *completely* equivalent on little-endian platforms > > (because nothing is declared volatile so the extra variables containing > > the CPU byte order fields can be completely removed by the compiler by > > going back to the memory the data came from if not enough registers are > > available). > > b = le_to_cpu(a) > b != FLAG > a = cpu_to_le(b) > is probably longer then > a |= FL:AG_LE; > n matter what. Obviously, with a flag this is true. But if you see my example below then you'll realise that most of the time you don't just do a single flag in a but multiple multi-bit values. > > Maybe it's "natural" to Intel people to think in little endian, but I'd > > guess most other people don't want to be bothered thinking about > > endianness in every single line of code > > I still argue that you will have more swap operation in the code > meaning that you also will have to be aware of endianity at least with > your definition of logical boundaries. Not considering single bits, you will have fewer swap operations as I've shown in my example code. And you're only hiding the fact that you have many more logical swap operations, most of which are of course constant, when you do consider single bits. > This I will fix. This just another of exemption of our approach. There's nothing you can fix here. It's not an exemption of your approach, it's a logical consequence of your approach. Making exemptions for things like this in your approach will imho most likely make the code even worse. But I'm interested to see how you want to "fix" this without going to CPU-defined constants instead of LE-defined constants. And once you start *mixing* the two approaches things will *really* be confusing, so you really do need to write it the way I wrote (almost quoted but simplified). johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
