nevin1@cbnewsc.ATT.COM (nevin.j.liber) (08/24/89)
In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >No, the question is not a JOKE. It is a stupidity in UNIX which causes the >problem. I have used other systems in which the main program could have >any name whatever, and even in which the entry need not be to a main program, >while a main program is present. I have even used it. It has finally dawned on me on what Herman Rubin thinks C is. Now I know why stuff like entry points and hardware registers and NAND gates bother him. He must have heard the phrase "C is kind of a portable assembler". This phrase is a misnomer! C is closer to (and I really hate to call it this because I KNOW that someone is going to misinterpret me) a portable assembly language than a portable assembler. C defines a virtual machine which maps fairly efficiently onto a wide variety of current computer architectures. What this allows one to do is write code which will work unaltered on a lot of different machines. This is why the implementations of other languages (such as C++, Eiffel(?), etc.) compile (and I mean compile, not translate. Compilers output syntactically correct code, be it assembler, p-code, or C; translators may rely on the post-processor to catch the syntactical errors) to C; it is portable. Now let's look at what Herman wants. He wants to be able to hand-optimize his code; to know which variables go into which registers, what branch instructions are used, etc. In other words, he wants an extra-fancy macro assembler! C is not this, and it will never be this! He complains that he can't do everything in C that he can in assembler. Of course not! C was never intended to replace an assembler (except perhaps on a PDP-11 :-))! Please stop complaining that C doesn't fit your want of a super-duper macro assembler; C isn't one, it is a *language*. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
bbadger@x102c.harris-atd.com (Badger BA 64810) (08/25/89)
In article <2659@cbnewsc.ATT.COM> nevin1@ihlpb.ATT.COM (nevin.j.liber,55528,ih,4f410,312 979 4751) writes: >In article <1496@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >>No, the question is not a JOKE. It is a stupidity in UNIX which causes the >>problem. I have used other systems in which the main program could have >>any name whatever, and even in which the entry need not be to a main program, >>while a main program is present. I have even used it. > >It has finally dawned on me on what Herman Rubin thinks C is. Now I >know why stuff like entry points and hardware registers and NAND >gates bother him. He must have heard the phrase "C is kind of a >portable assembler". This phrase is a misnomer! > I don't speak for Mr. Rubin, but it seems to me you are leading this discussion away from the topic. The question here was whether ``main()'' is an attractive feature of the C language. That is, why can't all routines have a programmer-chosen name? This is an issue in expressiveness, and questions an apparently gratuitous irregularity in the language. The reference to entry points had to do with how the current implementations of C manage to call the first routine. The starting address specified in ``ld -e epsym'' (that is, the entrypoint symbol) isn't the same thing as the address as the first routine called. -e epsym Set the default entry point address for the output file to be that of the symbol epsym. - When the link editor is called through cc(1), a startup routine is linked with the user's program. This routine calls exit( ) (see exit(2)) after execution of the main program. If the user calls the link editor directly, then the user must insure that the program always calls exit( ) rather than falling through the end of the entry routine. All this talk about implementation is to rebut the contention that ``main()'' is somehow critical to the C language definition by providing explicit implementation details to how you might build a program. We don't want to change the name of ``main()'' so that we can perform low-level assembler-like symbol definitions, we're telling you how to use the linkage machinery to remove a restriction in C. In most cases all the language and system-dependent start-up and shutdown are encapsulated in ``crt0.o''. ``main()'' can be, and probably is, compiled as a _completely_ normal subroutine. The only thing missing to allow link-time election of a main routine is a mechanism in ``crt0.o'' to call a specified function. Somehow aliasing ``main'' to the desired symbol seems to be a suitable mechanism. Bernard A. Badger Jr. 407/984-6385 |``Use the Source, Luke!'' Secure Computer Products |``Get a LIFE!'' -- J.H. Conway Harris GISD, Melbourne, FL 32902 |Buddy, can you paradigm? Internet: bbadger%x102c@trantor.harris-atd.com|'s/./&&/g' Tom sed expansively.
dhesi@sun505.UUCP (Rahul Dhesi) (08/29/89)
In article <2600@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes: >The question here was whether ``main()'' is an attractive feature of >the C language. That is, why can't all routines have a programmer-chosen >name? This is an issue in expressiveness, and questions an apparently >gratuitous irregularity in the language. The question is really broader, and much more philospphical: Should information about the entry point be encoded in the C program itself, or should it be external to the program? (The "entry point" of a C program is where the C virtual machine defined by the language begins execution, which may not be the place where execution actually begins.) For my money, I had better be able to tell, just by looking at the C source, where execution will begin. Whether I do this by grepping for 'main.*(', or by searching for '#pragma begin_here' or 'hey mr. linker, make my day, start this program here i say' etc., is a syntactic detail in the same category as using { and } rather than BEGIN and END. -- Rahul Dhesi <cirrusl!dhesi@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi