Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site unc.UUCP Path: utzoo!watmath!clyde!akgua!mcnc!unc!tim From: tim@unc.UUCP (Tim Maroney) Newsgroups: net.lang.c Subject: What Can't C Do? Message-ID: <6900@unc.UUCP> Date: Mon, 12-Mar-84 15:41:47 EST Article-I.D.: unc.6900 Posted: Mon Mar 12 15:41:47 1984 Date-Received: Tue, 13-Mar-84 19:41:56 EST Organization: CS Dept., U. of N. Carolina at Chapel Hill Lines: 71 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@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.