What Can't C Do?

[Tim Maroney]

The greatest advantages of C are its brevity and its generality.  There is
very little that you can't do in C, unlike other "general-purpose"
programming languages such as Fortran and Pascal.  However, there are some
things that C can't do, at least not without postprocessing the assembly
language output.  That practice is A Very Bad Thing Indeed, since it tends
to be very nonportable (some C compilers don't even produce assembly
language! -- but that's obviously not the only reason for nonportability)
and difficult for anyone except the person who wrote the code to understand.
Furthermore, it makes assumptions about the format of the assembly code that
may be invalidated by an intelligent optimizer.  You can turn off the
optimization in most such cases, of course, but then you are sacrificing
performance.

Now that an ANSI standard for C is in the works, people are putting forth
their suggestions for "improving" C again.  Most of these involve making it
easier to do certain things that it is possible to do now (for instance,
dynamically typed data like Pascal's variant records).  I'm not interested
in these very much, but I am interested in widening C's generality and thus
ending once and for all this practice of assembly language postprocessing.

The most common use of ALPP (as I'll call it for short) seems to be changing
variable references into references to OS-specific objects such as device
registers.  In these cases, optimization is usually turned off as well, so
that each time the object is referenced in C code a real reference is
generated (instead of using modern register-optimization techniques).  There
was some discussion of this on this group a few months back, and the only
"solution" I can recall was to introduce a new storage class specifier (one
suggestion for its name was "volatile") for such variables.  This solves
only the problem of having to turn off optimization, though; you still have
to do ALPP to give the references the proper name.  A better solution would
allow the C programmer to declare a certain identifier as being equivalent
to an OS name, and the variable would implicitly be considerd volatile.
Logically, the declaration is three-operand (type, identifier, OS name)
rather than the normal C two-operand (type, identifier), so the syntax is a
little problematic.  One solution would be to disallow initialization of
such variables, and put in the initialization field a string with the OS
name; this would be consistent with the C practice of making code weird and
hard to understand. :->  I'd like to hear (in this group rather than in
mail) other suggestions for the syntax of this solution, or other solutions
to the same problem.

Another not-too-uncommon use for ALPP is global register declaration, that
is, changing all references to an external variable to register references.
This is useful in language interpreters (to use registers for function
return values), and possibly in other applications as well.  Syntactically,
this is easy to solve; just allow the "register" storage class specifier at
the external level.  However, it presents some problems for the compiler
when dealing with separately-compiled files, since the register used for
each identifier must agree in all the object files.  It would not be a good
idea to defer this to the linker, since linkers typically perform only the
function of filling in variable and function addresses; on some
architectures, filling in register references is a significantly different
task.  I'd like to hear suggested solutions for this problem as well, also
posted and not mailed.

That about wraps it up for now.  I'd like to hear other uses of ALPP and
suggested solutions.  I'd also like to know what "asm" is most commonly used
for, again preferably with ways to eliminate its necessity or at least to
clean it up.

I'll leave you with about the only change I'd like to see in C that doesn't
increase generality: string comparison operators.  Ideally, these would just
be "==", "<", ">", "<=", and ">=", but those already have meaning for
strings (i.e., char *), that of pointer comparison.  Either new operators or
a new built-in data type would be needed.
--
Tim Maroney, University of North Carolina at Chapel Hill
mcnc!unc!tim (USENET), tim.unc at csnet-relay (ARPA)

All opinions expressed herein are completely my own, so don't go assuming
that anyone else at UNC feels the same way.