summary of historical keyword info
James Jones
jejones at mcrware.UUCP
Sat May 11 10:40:57 AEST 1991
Here's the long-overdue summary of the information received about the
historical C keywords. Apologies to all those kept waiting, and thanks
to those who emailed information. (The latter had nothing to do
with any waiting by the former. :-)
The people who generously contributed their knowledge via email are:
Ken Yap, Gordon Burditt, Guy Harris, and Steve Summit. The following
is my summary, and any grammatical or factual blunders are my own. :-)
Here goes:
1. asm
Small C-based compilers have/had #asm/#endasm directives, with
the intervening text being literally inserted into the compiler's
assembly-language output. This separation of function in at least
some cases interacts unfortunately with parser lookahead, so that
the assembly language might not appear where one would expect.
Different pcc-based compilers support different forms of "asm";
the earlier form was "asm(<string constant>);" which could appear
either within or outside of functions. (This format is the "common
extension" referred to in the ANSI C standard.) The string constant
was literally inserted into the compiler's assembly-language output.
Evidently this facility also got into trouble with the parser in
some contexts; enclosing asm(); in braces would solve the problem.
A later PCC would let (lets?) one declare assembly-language
procedures to expand inline.
Some compilers treat asm more like a // comment, i.e. everything
to the beginning of the next line is taken as assembly language.
gcc, of course, has a very extensive asm() facility.
The early assembly-language escapes gave one no way to
symbolically refer to variables, so that their use requires some
experimentation (and of course is highly vulnerable to changes);
neither did they let one communicate side-effects to the compiler.
More recent ones substitute appropriate effective addresses for
variable names appearing in assembly-language escapes, and let one
indicate what operands are read and written.
I've not been able to find out whether the original Ritchie PDP-11
C compiler provided for assembly-language escapes.
2. entry
Neither the folks who helped with information nor I knew of any
compilers that supported "entry". Indeed, K&R 2 (the New Test-
ament? :-) says it was never used and refers to it as "stillborn."
It may have been intended to be analogous to FORTRAN's ENTRY, i.e.
indicating multiple entry points to a function.
3. fortran
The "fortran" keyword has been used to specify that a function
is to be called, or if it's being defined, is to use, the calling
conventions of FORTRAN, or possibly generic "anything other than
C (that hence doesn't have to worry about varargs)" calling
conventions. Since ANSI constrains variable argument lists to
functions declared with the ellipsis syntax, an ANSI C compiler
can presume it knows where it potentially more efficient parameter
passing mechanisms are allowed; if this method matches that of
the local FORTRAN compiler, the "fortran" keyword may not be
needed.
Once again, thanks to those who helped, and apologies for not posting
this summary sooner.
James Jones
More information about the Comp.lang.c
mailing list