Ambiguous C?

[Mike Haertel]

In article <10163 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
> [ ... omission ... ]
>To branch from mostly-C code to assembly language level would require
>either a function call, which MIGHT break were you to change compilers,
>or in-line assembler (such as the "asm" extension found in many C
>implementations).  If you've done either of these, you've probably
>found reasons why they're less than fully satisfactory.
>
> [ ... omission ... ]
>
>Device driver code is obviously extremely machine dependent, but for
>example UNIX device drivers, entirely written in C, have been ported
>much more readily from PDP-11s to VAXes than would have been possible
>if they had been written in assembly language.

I'd like to make it clear that I am not advocating writing device drivers
in assembly language.  I was once involved with moving an RAxx driver
from a Vax to a pdp11, so I am, to say the least, not wholly unappreciative
of the benefits of writing device drivers in a real language.  I am also
not an advocate of asm escapes.

But for the particular situation you were suggesting, which might pop
up more than once on the same machine anyway, rather than resort to
compiler hacks to do the atomic set-a-bit operation, I would say
in the source code something like:

	...
	atomically_or_to_address(random_value, DEVICE_REGISTER_ADDRESS);
	...

Unlike any (open coded) compiler hack, this says exactly what it means.
And then atomically_or_to_address() could be a macro that expands to a
compiler hack, it could be an assembly language subroutine, or whatever.
The point is that the icky machine *and* compiler dependent atomic or
stuff would be isolated in one tiny spot, well away from the code that
is conceptually independent of exactly how atomic or'ing is done, and
clearly labeled as machine- and compiler- dependent.
-- 
Mike Haertel <mike at stolaf.edu>
main() ??< printf("hello, world??/n"); ??>