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