Hacker News Reader

Helper functions or macros are just as clean as the bitfield syntax. That said, hardware register access is one of those things that is intrinsically tied to a specific platform (and if you target multiple platforms, it will already be behind an abstraction layer), so you can usually know the quirks of how the toolchain for that platform supports bitfields, and use them accordingly. Still more work for people reading the code, though since there are a lot of hidden assumptions behind that deceptively simple "=" than with an explicit mask and shift.

>Helper functions or macros are just as clean as the bitfield syntax.

They can be, if done right, but then I have to remember the names of all the helper functions and macros. :-) An IDE can auto-complete bitfield names.

>Still more work for people reading the code, though since there are a lot of hidden assumptions behind that deceptively simple "=" than with an explicit mask and shift.

Depends on the platform. IIRC on ARM a bitfield access is masking and shifting, only done by the compiler instead of me. With optimized code I often have to look at the disassembly anyway if I want to know what's really going on.

> Depends on the platform. IIRC on ARM a bitfield access is masking and shifting, only done by the compiler instead of me. With optimized code I often have to look at the disassembly anyway if I want to know what's really going on.

ARM supports native bitfield loading[1], extraction[2] and clearing[3].

1 - https://developer.arm.com/documentation/ddi0602/2022-03/Base...

2 - https://developer.arm.com/documentation/ddi0602/2022-03/Base...

3 - https://developer.arm.com/documentation/ddi0602/2022-03/Base...

There are tens of thousands of different ARM chip types.

Many of them get it right.

Another trap with macros is that they might introduce extremely hard to detect bugs. You macro for clearing a bit like for example:

  #define CLEARBIT(a,p) = ((a) &= ~(1 << (p)))

might not work correctly if your datatype is something "exotic" like a long. An inlined function might be the better choice.

Otherwise you would need to define specific macros again:

  #define CLEARBITLONG(a,p) = ((a) &= ~(1L << (p)))

These bugs can steal hours of your time, especially on embedded systems where debugging is less accessible.

  #define CLEARBIT(a,p) = ((a) &= ~((typeof(a))1 << (p)))

That is clearly better provided the compiler supports it. Less portable but it should really be a part of ISO C in my opinion.

I remember being surprised that setting an individual bit on an AVR hardware register in assembly was so much shorter than doing all that C bit masking stuff.

It feels weird to see arguments like this when you could just use a language (C++ being the elephant in the room here) that lets you define methods, then call those methods instead.

A method that does will often (depending on the architecture) have much more overhead than a struct lookup. If you're doing hardware stuff, you often care about performance.

Inlining?

Every C++ compiler released in the last 30 years will trivially inline oneliner getter functions, member or not.

True, but this is making the assumption that whatever pointer offsets, shifting, and masking that you have in your method, to extract the 9th bit in the 5th word of a 512 bit struct, will result in the same operations as the simple struct access. It very well could be so (certainly for some architectures, most likely not for others), but I don't think all this complication is justified when a struct is available, especially if you're someone writing code for hardware, where these concepts are more known/less scary.

Compilers do generate instructions specified in functions correctly, inlined or no.

> Compilers do generate instructions specified in functions correctly, inlined or no.

Well, clearly that's not always the case, as shown in the article, and which is what started this comment chain.

But, I'm not sure how you reached that interpretation. I'm saying that the code that you put into the function will result in some operations, whatever they may be, inline or not. The struct access will result in some operations. The those two sets of operations may be different. Some architectures have specialized instructions for bitfield access. There's a good chance that the complier won't convert the shenanigans in your method to those specialized instructions. Maybe! It requires an understanding of your particular situation. But some people's work exist in a context where this is a reasonable choice, for them.

If you make bitfield members, and access those in an inline function, and code generation for bitfields tickles a bug, the access being in an inline function won't help.

If you code a shift-and-mask in an inline function, instead, your odds are better, same as if you made a macro for it.

You can equally define helper functions to update registers in C.

Definitely, but it's more ergonomically annoying with IDE stuff others complained about. [1]

[1] https://news.ycombinator.com/item?id=31185723

This just illustrates how even in imperative languages like C/C++ programmers naturally reach for more declarative approaches. Type punning with a union is much the same story. It's just unfortunate that C/C++ has so many foot guns.

By that logic isn't all abstraction 'declarative code'?

Readable code that does not necessarily execute what it says does nobody any favors.

This is why we test our code, or build in runtime checks, before releasing it.

Absolutely, it makes far more sense to do some basic sanity checks instead of writing painfully awkward code out of fear of a hypothetical.

The standard may be flexible, but the behavior of a given compiler on a given platform will be consistent and very unlikely to change in the foreseeable future.

Wrong.

Perfectionist nerds love to obsess over a million scenarios which only exist in their head, or in obscure edge cases. This is not productive. Perfectly portable, future-proof, CPU-bug-proof code simply does not exist.

The only thing to be aware of here is that you shouldn't be trying to transfer data from one platform to another, loading it directly into memory, which is an insane thing to do in any case.

You may ignore field experience freely if you are insulated from all consequences.

You really are failing to get this!

Testing formally-correct code can only ever find bugs in the exact compiler release and physical CPU chip you run the test on.

The bugs cited show up in various compiler releases and various chip steppings. Unless your code will only ever run on that exact machine, you have not tested it.

> Unless your code will only ever run on that exact machine, you have not tested it.

I don't understand this sentence. That is the purpose of the runtime check, to make sure the code generated by a buggy compiler, on a specific architecture, doesn't try to run. Bug reports can then be filed, as they should be.

If you're writing a Linux kernel module (known compiler) for a known architecture, which is where this is often used, then you have a known environment, so there's little risk, except the rare compiler bug, which is a risk that extends far beyond packed structs.

This is something that I've used, and I've seen used, often in the hardware world. I'm having difficulty sympathizing with all the fear in this comment section. Don't use it if its use can't be made rational, for you. But please don't tell me that I'm failing to get something that I am familiar with.

Still not getting it.

I certainly don't understand what you're trying to say, and replying with four words definitely won't help me.

Perhaps there's some confusion of what a runtime check is. A runtime check is executed at runtime, which means that it will be executed after compilation with a specific compiler, on a specific architecture, in the end user system. The runtime check verifies correct struct operations at runtime, as part of the initialization, and aborts the driver load, with a nice system message, if improper packed struct behavior (among other things) is seen. This covers your concern here:

> Unless your code will only ever run on that exact machine, you have not tested it.

It literally is tested on every machine, when the driver is loaded.

This runtime check handles the cases where a customer might try to run it on some new hardware/toolchain that we don't officially support. The official supported cases only have risk of new compiler bugs, since we only support certain architectures. Hypothetical compiler bugs are a problem for all software, and shouldn't be used to drive software design, beyond making sure there is good testing, which has nothing to do with compilers.

Maybe I'm missing something.

edit: ncmncm, I can't reply to you, but since I have code that does what you say is impossible, and since my comment already responds to what you wrote, I would suggest reading all of my comments, fully, a second time.

Yes. You will never have a startup test of all the instructions used, in all the circumstances where they are used. Startup tests are useful for checking the presence or absence of certain advertised features, such as SIMD instructions. They are useless for buggy compilers and buggy chip implementations.

And, what would the code do if it detected such a bug? Abort, or run other code that works OK anyway. So, run that code all the time, and you don't need to try to check.

On an AVR if you write this in C

  PORTB |= (1<<4);

You get this in assembly

  sbi PORTB, PINB4

However if you write

  PORTB = PORTB | (1<<4)l

The compiler instead emits.

  sbi PORTB, PINB4

I ported some code once where they went to the trouble of defining the registers as bit fields. In that case

  portb.pin4 = 1;

compiled to

  sbi PORTB, PINB4

If you are doing full functional tests of your ROM app on on each mask stepping before it is soldered into thousands of boards, congratulations, the warning isn't for you.

amd64 bugs tend to be in newer parts of the ISA. ARM provides chip makers very thorough tests, to protect their brand (though not all chip makers fix all the bugs tests find). So, many programmers will not encounter bitfield bugs. But code gets around, and tests are always less thorough than we wish.

Maybe I'm naive, but I don't see why fully functional runtime tests are required. The only purpose of a runtime tests is to test things that could vary, at runtime, like architectural incompatibilities, with memory layout things like endianness and bitfields being an example. These are trivial to implement in a few dozen bytes. If you have a ROM soldered into boards, then absolutely none of this would be a concern since the architecture would be intimately known, so I'm now completely lost on your point. Anyways, cheers!

Why not

    old_divider = (SpiRegs.CONFIG_REG >> SPI_CONFIG_CLK_DIVIDER_POS) & 1;

Slightly cleaner IMO.

Because the divider isn't necessarily one bit. Multi-bit register fields are very common. You can certainly hardcode the numbers if you want:

  old_divider = (SpiRegs.CONFIG_REG >> 24) & 0xff;

which is easier to read but also easier to mess up when you're writing it. It's best to use the vendor's register definitions where possible. Although then you have the possibility of using the wrong #define constant, because all of these are just integers so the compiler can't tell you if you made a mistake.

Another "fun" issue with using numbers is that sometimes an int is 16 bits, so you have to do (13 << 24ul) instead of (13 << 24).