| |||||||||||||
A perf ABI fixA perf ABI fixPosted Sep 26, 2013 0:19 UTC (Thu) by ncm (subscriber, #165)In reply to: A perf ABI fix by geofft Parent article: A perf ABI fix
Gcc and Clang both support C99 inline functions. All the operations defined above can be expressed directly in type-checked C, without preprocessor macros, with identical runtime performance.
There are still places for CPP macros, but this isn't one of them.
(Log in to post comments)
A perf ABI fix Posted Sep 26, 2013 9:38 UTC (Thu) by etienne (subscriber, #25256) [Link]
> All the operations defined above can be expressed directly in type-checked C
C cannot have function with bitfields parameters (i.e. parameter of 3 bits), so the simple bitfield version:
The equivalent in C is:
If the bitfield is signed, the C function gets even more complex, and prone to off-by-one bugs.
I have seen so much crap with #define (files with 10000+ #define lines, with bugs) that I would say bitfields is the future... let the compiler manage bits and bytes and let the linker manage addresses.
A perf ABI fix Posted Sep 26, 2013 10:40 UTC (Thu) by mpr22 (subscriber, #60784) [Link] Any time I see a :1 bitfield, I wonder why the author didn't just set up an unsigned char/short/int/long/long long and define compile-time constants for the bit(s). Any time I see a :n (n > 1) bitfield, I wonder what makes the author simultaneously believe that (a) it's important to squash that value into a bitfield instead of just using an int*_t or uint*_t (b) it's not important for people to be able to look at the code and predict what it will do. (And any time I see a bitfield without an explicit signedness specifier, I wonder if I can revoke the author's coding privileges.)
A perf ABI fix Posted Sep 26, 2013 11:51 UTC (Thu) by etienne (subscriber, #25256) [Link]
> bitfield, I wonder why the author didn't just set up an unsigned char
Well, I was talking about describing the hardware, for instance a PCIe memory mapped window which control complex behaviour.
For code unrelated to hardware, and not mapped to a fixed format (like for instance the structure of an Ethernet frame), then using bitfields is a lot less important.
A perf ABI fix Posted Sep 26, 2013 12:40 UTC (Thu) by mpr22 (subscriber, #60784) [Link] Yes, you're describing exactly the situation I'm implying with my comment. I've worked with hardware a lot. I've worked with hardware that has default settings useful to exactly no-one. I've worked with hardware that sometimes fails to assert its interrupt output and then won't attempt to assert an interrupt again until the interrupt it didn't assert has been serviced. I've worked with hardware with complex functional blocks that were pulled in their entirety from a previous device, but only half-documented in the new device's manual. I've worked with hardware with read-to-clear status bits, hardware with write-zero-to-clear status bits, hardware with write-one-to-clear status bits, and hardware with combinations of those. Thanks to that, I've spent enough time staring at bus analyser traces that I have come to appreciate code of the form ""read register at offset X from BAR Y of PCI device Z'; compose new value; write register at offset X from BAR Y of PCI device Z", because I can directly correlate what I see on the analyser to what I see in the code - and, even better, I can quickly tell when what I see on the analyser doesn't correlate to what I see in the code. Most hardware isn't bit-addressable. Bitfields in device drivers look an awful lot like a misguided attempt to make it look like it is.
A perf ABI fix Posted Sep 27, 2013 9:25 UTC (Fri) by etienne (subscriber, #25256) [Link]
A also work with hardware, but mine may be working better.
Maybe FPGAs work better, at least read/write issues are dealt by VHDL teams. What I am saying is that ten lines of #define to write a memory map register do not scale; once the single block works, FPGA teams just put 2048 of them on one corner of the FPGA. Then, most of the errors you find is that the wrong "ENABLE_xx" mask has been used with a memory map register, or someone defined #define FROBNICATE_1 xxx #define FROBNICATE_2 xxx+2 ... #define FROBNICATE_256 xxx+512 but failed to increment for (only) FROBNICATE_42
When using C described memory mapped registers (with a volatile struct of bitfields), you can read a single bit directly (knowing that the compiler will read the struct once and extract the bit), but when you want to access multiple bits you read the complete volatile struct into a locally declared (non volatile) struct (of the same type).
A perf ABI fix Posted Sep 27, 2013 9:54 UTC (Fri) by mpr22 (subscriber, #60784) [Link] What I am saying is that ten lines of #define to write a memory map register do not scale; once the single block works, FPGA teams just put 2048 of them on one corner of the FPGA. It seems to me that dealing with an FPGA containing 2048 instance of the same functional block should only require defining two or three more macros than dealing with an FPGA containing one instance of that block. If it doesn't... you need to have a quiet word or six with your FPGA teams about little things like "address space layout".
A perf ABI fix Posted Sep 27, 2013 11:33 UTC (Fri) by etienne (subscriber, #25256) [Link]
> require defining two or three more macros
In that case the 10000's lines of #define is automatically generated by some TCL command nobody really is interested of reading, while "compiling" the VHDL.
A perf ABI fix Posted Sep 26, 2013 20:13 UTC (Thu) by ncm (subscriber, #165) [Link] What mpr said. Further, any use of bitfields to control hardware makes the driver non-portable to any other architecture. Further further, there is no way to know, ABI notwithstanding, how any particular compiler version will implement a series of bitfield operations, so use of bitfields makes your driver code non-portable even to the next release of the same compiler.Categorically, there is never any excuse to use bitfields to operate hardware registers. Use of bitfields in a driver is a marker of crippling incompetence. Publishing code written that way will blight your career more reliably than publishing designs for amateur road mines.
|
|||||||||||||