> Bare metal ain't dirty.
No, but it's not as solid as it sounds. What happens when version 2 of the hardware appears, and moves the bit to a different register?
> What happens when version 2 of the hardware appears, and moves the bit to a different register?
You adapt your code for that platform. I don't know why developers today have such a love affair with unnecessary abstraction. Abstract when you need to; never before.
The same thing when a new OS release break some API call.
I recall that the first thing that jumped out at me was that Chuck's code didn't have all those layers that my code had. There was the abstracted code on top and the hardware drivers on the bottom and very little in between. There was not a clear distinction in style at various levels as in my code where there were always someone else's code layered under mine that I could not or dared not change. Chuck's code looked abstracted and high level right from the bottom, the top used almost as many primitives as the bottom code. [1]
The confusion seems to come from the idea that a piece of code has to be either "abstract" all the way or "close to the metal" all the way. Why should it be? If you need to flip a bit in a peripheral between a call to some filesystem function and a call to memory page management function, just do it directly, don't invent a pseudo-high-level function just for that. Bare metal ain't dirty.
[1] http://www.ultratechnology.com/levels.htm