[comp.lang.c] summary of historical keyword info

jejones@mcrware.UUCP (James Jones) (05/11/91)

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

henry@zoo.toronto.edu (Henry Spencer) (05/12/91)

In article <6433@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes:
>   I've not been able to find out whether the original Ritchie PDP-11
>   C compiler provided for assembly-language escapes.

It didn't.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry