Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site tikal.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!houxm!vax135!cornell!uw-beaver!teltone!tikal!warren From: warren@tikal.UUCP (warren) Newsgroups: net.lang.c Subject: Re: Register functions ? Message-ID: <21@tikal.UUCP> Date: Fri, 21-Sep-84 15:07:20 EDT Article-I.D.: tikal.21 Posted: Fri Sep 21 15:07:20 1984 Date-Received: Tue, 25-Sep-84 21:39:48 EDT References: <12118@sri-arpa.UUCP> Organization: Teltone Corp., Kirkland, WA Lines: 68 As the recent originator of the topic of "Register Functions", I would like to mention that executing code in registers was not what I meant. I am not opposed to it, I just meant something else. Let me cast the idea in clearer form: C would benefit from a new storage class, I hereby dub "private". Private storage items, whether const or variable, would be not exportable. It would be impermissable to take the address, declare as external, or otherwise export a private item. One clear win is the "private function", which in this case means VERY STATIC. The privacy of an item means the optimizer in the compiler can take further liberties, for example, generating whatever form of function call it deems useful, short calls, inline functions (lets say an ordinary (outline ?) function is called exactly once -- which happens), and so forth. The "private" declaration is intended to get around the "aliasing" problem in C, where two expressions (say, "x" and "*y") cannot be assumed to point at different objects (they could both point to the same place). If x is declared "private", then y must point somewhere else. Note that the compiler is free to treat the "private" declaration as a comment, merely declining to optimize. Private variables could not be modified by a call to an external function, because its address could not be passed, even passing a pointer to a pointer to it (the private variable) would not happen, because its address is "secret". This means that if its value was in a register that is protected by function calls then its also valid there afterwards. Whereas today, a called function could have received the address of a static variable on a previous call, kept it, and then, as a "side effect", modified it on the latest call. The value in the register is then corrupted. ------------------------------------------------------------------------ Related but different topic -- varargs. A major advantage of making a varargs scheme part of the LANGUAGE is that the compiler could KNOW that other functions were not varargs, and could generate tighter code. If you declare it wrong (e.g. "extern printf" instead of "extern varargs printf" then its your funeral, which is true already. Note also that the compiler is free to treat the "varargs" declaration as yet another comment, perhaps by building into the preprocesor "#define varargs", and so forth. On architectures where no such scheme is possible, most systems written in C would simply fail anyway. On any architecture, the implementation of varargs must be taken into account by the compiler writers, in order generate function calls. It seems only fair to the compiler writers to give them full control of varargs, relieving them of the burden of writing a compiler that has to be compatible with a varargs package written by somebody else, someplace else, in the future ! If varargs can't be implemented by the compiler writer, chances are nobody else can either... On systems where only a half-hearted varargs can be built, and where the coder of printf, say, has to explicitly hack in argument counting or something, the compiler writers can still sneak in an extra argument (argc) to help the coder (but only if users declare it as varargs - which they can suppress with a #define - even if its a reserved word). Making varargs part of the language costs us little, and offers clear benefits. teltone!warren