Ambiguous C?

[Doug Gwyn]

In article <1943 at thor.acc.stolaf.edu> mike at stolaf.edu writes:
>I think this would be a really bad idea, and that it would be *much*
>better to use the assembly language.  You're never going to port code
>like this to a different machine anyway, so there is no loss for using
>the assembly language.

Ah, but there is a loss.
Such an access to a device register is only a tiny part of the code;
one is much better off using a higher-level system programming language
for the bulk of system programming.  You thereby obtain support for
data structures and so forth.  Portability is not the only reason for
using C (although it is commonly an important one).
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.

>In general I believe programs should say what they mean, and if they
>mean something obviously machine dependent they should say it in an
>obviously machine dependent way.  It is not hard to port machine
>dependent code, as long as the dependencies are clearly labeled and
>isolated from the portable code.

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 agree that nonportable assumptions should be clearly identified in
the source code, but you can do that in C.