fouts@orville.UUCP (03/26/87)
I am looking into it, but it will be slow going for me. You should be aware, that although GCC appears to be a production quality code generator, it does not include an assembler, loader, librarian or run time library; these are yet to come. For the time being, the best use for GCC on the ST is as a replacement code generator for an already purchased C compiler. Marty
phr@mit-hermes.UUCP (03/27/87)
In article <975@ames.UUCP> fouts@orville.UUCP (Marty Fouts) writes: >I am looking into it, but it will be slow going for me. You might have trouble getting it up on current Ataris. When GCC compiles a function, it first builds a syntax tree for the entire function before it begins to think about it. This is so it can do optimizations that need to know everything about the function. Unfortunately, it means that very large functions can take megabytes of memory to compile. In particular, GCC needs about 1.5 meg to compile its own instruction recognizer (a decision tree pattern matcher that is several thousand lines of hairy machine-generated C code). We may do something in a future release about breaking up large functions so they can be compiled in a fixed amount of memory. You wouldn't get the benefit of certain optimizations on such functions if this happened. On a Mega ST with 2 or more meg of memory, compiling the compiler with itself won't be a problem, of course. I don't understand the comment that GCC is best used as the code generator for another compiler. This makes no sense. GCC reads in C programs and produces assembly code. To run compiled programs, you need an assembler and linker, and a runtime library. The GNU versions of these things probably will not help Atari OS users as the load formats, etc. are all completely different. Now when Atari comes out with a machine that we can run the GNU kernel on...
fouts@orville.UUCP (03/27/87)
In article <2822@mit-hermes.AI.MIT.EDU> phr@hermes.UUCP (Paul Rubin) writes: >I don't understand the comment that GCC is best used as the code >generator for another compiler. This makes no sense. Let me put the remark back into the context you took it out of, and rephrase into small sentences so that it will make sense: (;-) The contex is that of a C compiler for the existing ST in the near future. The point was made with the understanding that FSF would be unable to produce a kernel that ran on the existing ST. The point was made with the uderstanding that FSF would be unable to produce an assembler, loader or librarian for the existing ST. The point was made with the understanding that FSF would require time to produce the source for the librarian. Given this context, the point is that existing ST users should not expect to be able to use the GNU C compiler as is. If an existing ST user wants to use the GNU C compiler, it may be possible. However, the GNU C compiler isn't (yet) a C compiler, all that it available now is a translator from C to assembler. For the phrase translator to assembler, I used the short hand code generator. This short hand is probably what confused you (;-) In a small way, I am trying to help FSF by obtaining the beta GNU C compiler, and in a way consistent with the GENERAL PUBLIC License, debug and port that compiler. FSF will benefit from this effor in exactly the way Stallman proposes in the GNU Manifesto. The C compiler has the same potential as GNU Emacs to be used outside of GNU. As Emacs runs on non GNU systems and is useful to non GNU users, so could the C compiler be. Further, GNU users, if there ever are any will benefit by the extensive beta testing of the GNU C compiler that multiple ports would afford. However (Flame on, Thrusters to FULL :-( The only response I've gotten, (both here from Paul Rubin, and elsewhere from Len Tower) from people who appear to be associated with FSF has been abuse. I would suggest that if FSF wants support from a user community, they would be better served by supporting that user community than by p*ss*ng on it. Marty
phr@mit-hermes.UUCP (03/30/87)
In article <1014@ames.UUCP> fouts@orville.UUCP (Marty Fouts) writes: >However (Flame on, Thrusters to FULL :-( The only response I've >gotten, (both here from Paul Rubin, and elsewhere from Len Tower) from >people who appear to be associated with FSF has been abuse. I would >suggest that if FSF wants support from a user community, they would be >better served by supporting that user community than by p*ss*ng on it. > >Marty I regret Marty's having felt abused by my article. I was trying to be friendly and helpful, pointing out some difficulties he might encounter in doing his port, and expressing my bewilderment at his suggestion that "the best use of GCC is as a code generator for another compiler". I haven't seen what Len Tower sent Marty, but I know Len and doubt very much if he said anything that he intended to be the least bit abusive. To most compiler hackers, "code generator" means the part of a compiler that emits machine code (or assembly code) from whatever internal representation the compiler has made for your program. Other parts of a compiler include the lexical analyzer, the parser, etc. Assemblers and loaders are generally considered distinct programs from compilers. It sounded like Marty was proposing to use a different compiler's front end with a GCC back end, which for various reasons isn't such a good suggestion (e.g. it probably requires you to have source code for the other compiler). It turns out that Marty was using the term "code generator" to mean what is usually called a "compiler", and apparently "compiler" to mean "compiler, assembler, linker, and runtime library". His ";-)" suggests he expected me to have understood this; however, I didn't. (N.B. I am not trying to get into an argument over terminology. It's just that people must agree on definitions in order to understand one another, and in this case, we didn't). Back to the subject of porting GCC to an ST: I would be happy to see this done and will say a little more about what is needed: basically, an assembler and linker and a runtime library. Marty has suggested (if I now understand his suggestion) using these parts from an existing ST C compiler system. This might be a good way for ST users interested in playing with GCC to get started quickly, but it has a few problems: 1) those systems might not include an assembler, or at least not not one with the same assembly format that GCC produces (although GCC could be changed) 2) Similarly, the calling conventions of the runtime library might not be compatible, and 3) most important, all the existing ST compiler systems that I know of are proprietary. However, I believe there are some free assemblers and linkers around. If there are no suitable free assemblers available, it might be possible to adapt the GNU assembler (which is not yet finished). The GNU linker probably won't be of any use for this because the Gemdos load format is so different from GNU's. You'll also need to have a runtime library to interface with Gemdos primitives and/or talk to the ST hardware. An Atari-using friend of mine who has been interested in porting the compiler says that this shouldn't be too hard to write. There are also some machine independent parts for which there is free code available that you could start from. Contact me by mail if you want help with this. Please stop feeling abused, and don't feel discouraged from trying to port GCC, and do distribute your results when you have some.
fouts@orville.UUCP (03/31/87)
In article <2824@mit-hermes.AI.MIT.EDU> phr@hermes.UUCP (Paul Rubin) writes: > >I regret Marty's having felt abused by my article. I was trying to be >friendly and helpful, pointing out some difficulties he might >encounter in doing his port, and expressing my bewilderment at his >suggestion that "the best use of GCC is as a code generator for >another compiler". I haven't seen what Len Tower sent Marty, but I >know Len and doubt very much if he said anything that he intended to >be the least bit abusive. In response to my flame, Paul Rubin writes an apparently conciliatory note in which he does precisely what I took exception to. A more proper use of the editorial form would have been to quote ". . . the best use of GCC is as a code generator for another compiler." which would have made clear that the quote had been edited in such a way as to remove context which modified its meaning. To the audience to which I addressed my note -- the Atari ST user community -- the word "compiler" implies producing a runable image from a source program, which is the meaning I took from the first request and was responding to. I thank Paul for his constructive comments and condemn him for his bad editorial habits. I find being misquoted to be very distasteful; especially when my original comment was botched and needs clarification anyway. (:-( I am also leary of individuals who assume that the portion of the community of experts that they belong to is "most". To most of the compiler writers (about 10) that I know, "compiler" means two things, depending on the context. When marketing a product, they think of compiler in the way users do -- as a way to generate a runnable binary from source code -- when working internally, they think of "compiler" as that part which translates the source representation into some format (possibly text assembly, possible binary load modules) which is processed by the rest of the user's "compiler". I try to keep these two usages clear by staying in context. I am glad Paul has clarified his misunderstanding of my remarks. I am also glad he expanded on what I should have said, rather than what I said. Paul is correct. What I had intended to say was that GCC, as it currently exists will only act as a compiler in the technical sense, not in the consumer sense; and that as such, it would require obtaining an assembler, a loader, a librarian, and a set of libraries to be useful. His discussion of these things does a good job of explaining the problems using GCC this way. A further problem is that a thorough port to ST would involve generating code for each of the most popular library formats, or providing a translator for modules produced by the formats, as is done by some of the commercial products. It is my intent to use GCC on the ST (if I can get around all of these obstacles) to generate code for an existing (as of yet unspecified) commercial assembler and loader. I have access to a public domain librarian and will probably use it. I have not gotten far enough to figure out what I'm going to do about the runtime environment; although I will develop bindings to allow access to GEM. However, if anyone can point me at the source (in C or PASCAL) for an assembler, loader, and librarian, as well as any pieces of the ANSI Draft runtime library I can use; I will use those. Marty
cmcmanis@sun.UUCP (03/31/87)
In article <1090@ames.UUCP>, fouts@orville (Marty Fouts) writes: > To the audience to which I addressed my note -- the Atari ST user > community -- the word "compiler" implies producing a runable image > from a source program, which is the meaning I took from the first > request and was responding to. This is a meta-note on the above comment by Marty. I disagree that the "Atari ST user community" is unable to distinguish between a compiler and a linker. To me personally this seems somewhat of an insult to the intelligence of the entire net, but I may be just over sensitive. > I am also leary of individuals who assume that the portion of the > community of experts that they belong to is "most". To most of the > compiler writers (about 10) that I know, "compiler" means two > things, depending on the context. When marketing a product, they > think of compiler in the way users do -- as a way to generate a > runnable binary from source code -- when working internally, they think > of "compiler" as that part which translates the source representation > into some format (possibly text assembly, possible binary load > modules) which is processed by the rest of the user's "compiler". Actually it is primarily the UNIX cc interface that conveys this misconception. If you include the base of MS-DOS users who use MicroSoft or Lattice C, you will find that they expect to run a linker to make the .EXE file after compiling the source into object modules. Besides the frontend 'cc' the only other really popular 'all-in-one' compiler I can think of is Turbo PASCAL. Further I would contend that it is a disservice to the naive user community to redefine the meaning of the word compiler to refer to something that creates and executable directly from the source. Since this same user might unknowingly buy a 'compiler' that conforms to the definition that has been in use for the last 20 years and find out it did not do the linking automatically. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
jdg@elmgate.UUCP (03/31/87)
In article <15901@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: >In article <1090@ames.UUCP>, fouts@orville (Marty Fouts) writes: >> To the audience to which I addressed my note -- the Atari ST user >> community -- the word "compiler" implies producing a runable image >> from a source program, which is the meaning I took from the first >> request and was responding to. > >This is a meta-note on the above comment by Marty. I disagree that the >"Atari ST user community" is unable to distinguish between a compiler >and a linker. To me personally this seems somewhat of an insult to the >intelligence of the entire net, but I may be just over sensitive. > Bravo Chuck. No your not overly sensitive. I agree 100%. Marty came off as a being totally ignorant of the actual 'compiling' process. Yet he claims to start porting GCC. So he must be reasonably intelligent, right? So why all the fuss? As to his reference "the Atari ST user community", even *I*, who has NEVER written a compiler nor am likely to, know that the compiler does NOT assemble and link my object module. A compiler 'driver' or 'shell' may, but the compiler should not. Indeed I will NEVER AGAIN purchase a compiler that will not produce an assembly language output file. I disagree with Marty almost as strongly as he took exception to Paul. Marty, I might suggest it is you who need to clarify your language. What you believe the word 'compiler' means may do on CompuSewer, or a local BeeBeeEss, but not here. Gives us a little more credit than that. >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com >These opinions are my own and no one elses, but you knew that didn't you. -- Jeff Gortatowsky {seismo,allegra}!rochester!kodak!elmgate!jdg Eastman Kodak Company These comments are mine alone and not Eastman Kodak's. How's that for a simple and complete disclaimer?
manis@ubc-cs.UUCP (03/31/87)
I am aware of *no* correct usage for the word "compiler" as meaning "a
program which translates source code into a runnable image", except in
situations where linking is not done. A compiler is always part of a
programming environment, not the whole thing. Compilers produce linkable
object code which cannot be run without linking. This is not the technical
use of the term, but the common use (except in the phrase "the compilers of
this cookbook have taken great pains not to include recipes requiring animal
or vegetable matter"). Sorry, I just wanted to clear that up.
Now, as someone who has just purchased Mark Williams C (a steal at US$119
from Microtyme), can anybody tell me what I would gain by running GCC on my
ST? I know that GCC generates outstanding object code, but I have yet to
write a compute-bound program for my machine (actually I have written one or
two, but nothing short of a floating-point coprocessor could speed them up
substantially). What are the other advantages?
-----
Vincent Manis {seismo,uw-beaver}!ubc-vision!ubc-cs!manis
Dept. of Computer Science manis@cs.ubc.cdn
Univ. of British Columbia manis%ubc.csnet@csnet-relay.arpa
Vancouver, B.C. V6T 1W5 manis@ubc.csnet
(604) 228-6770 or 228-3061
"BASIC is the Computer Science equivalent of 'Scientific Creationism'."fouts@orville.UUCP (03/31/87)
In article <15901@sun.uucp> cmcmanis@sun.uucp (Chuck McManis) writes: >Actually it is primarily the UNIX cc interface that conveys this >misconception. If you include the base of MS-DOS users who use MicroSoft >or Lattice C, you will find that they expect to run a linker to make >the .EXE file after compiling the source into object modules. Besides >the frontend 'cc' the only other really popular 'all-in-one' compiler I >can think of is Turbo PASCAL. > >Further I would contend that it is a disservice to the naive user community >to redefine the meaning of the word compiler to refer to something that >creates and executable directly from the source. Since this same user >might unknowingly buy a 'compiler' that conforms to the definition that >has been in use for the last 20 years and find out it did not do the >linking automatically. Maybe it is the people who market to the people who use that I'm really thinking of (;-). None of my survey of 10 compiler writers are involved in CC like products; their compiler experience varies from Fortran through ADA to Pascal. There isn't a single definition of compiler. I'm not redefining, I'm merely reporting. Of historical note, the concept of a single visible interface to the complete act of generating a binary from a source goes back much farther than CC. In IBM systems, sophisticated parameterized batch procedures substituted, CDC's NOS operating system has a 'RUN' command for Fortran which does a compile load and go; and the WATFOR, WATFIV, WATBOL systems were the outgrowth of earlier 'Load and Go' compilers. The first actual "compiler" I ever used was on an IBM 1620, for FORTRAN II, and it generated binary from source in one pass and then ran the binary. The original version had no way to save the binary; output of binaries onto card decks was a later add on.
fouts@orville.UUCP (03/31/87)
Ok, so I'm the only one that wants a source code to binary translation system to be packages so that the entire translation can occur. I also appear to be the only one who has ever walked into a computer store and asked to see their "compilers," rather than their "complete sets of source code to binary translation system." I'll try to be more verbose in the future. Marty
pes@bath63.UUCP (04/02/87)
Gosh, language wars. I think the language is evolving. When I was studying in
Cambridge (Massachusetts), and then still when I was writing compilers for
mainframes, the terms I was taught (and then used) defined:
assembler -- program to go from assembly language mnemonics to binary object
code (probably requiring linking).
compiler -- program to go from a higher-level language to binary object
code (probably requiring linking).
trnaslator -- program to go from any language to any other language,
including from a higher-level one to assembly language output.
However I note that the present books (Gries, and Aho and Ullman) define
compiler to mean 'from a higher-level language to either binary object or
assembly language' -- and, they define the code generator to be that part
of the compiler which produces the binary object or assembly language output
from the internal representation of the source produced by the parser (and
as muddled by any optimisation passes).
I'm a bit annoyed (must be old age) by this subtle shift in meaning, because
I think it eliminates a useful distinction. Still, looks like, in today's
terms, both of the previous arguers are using the terms correctly -- just,
unfortunately, differently. Sigh.donald@warwick.UUCP (04/03/87)
In article <597@elmgate.UUCP> jdg@aurora.UUCP (Jeff Gortatowsky) writes: [ loads of lines deleted... >These comments are mine alone and not Eastman Kodak's. How's that for a >simple and complete disclaimer? ] Leaving aside the vitriol, I noticed (from a brief glance at the gcc sources) that you need bison to generate the parser. I have tried to compile Bison on the ST using Mark Williams C, and although I succeeded in compiling all the source files (by dint of writing my own bcopy() and fudging around alloca()) I could not get the darned thing to link (thousands of symbolic relocations for the MWC cogniscenti). I assume this was due to sloppy coding on the part of the FSF i.e. char * == int assumptions etc. Anyway what I want to know is, has anyone compiled Bison successfully on the atari? If so, using which compiler? Also, does anyone have any documentation for Bison? If so, can I have/pay costs for it? Please please PLEASE mail me rather than posting to the net; we get a very small percentage of the stuff posted here, so I often never see replies to my postings. I will of course summarise to the net. Thanks in advance, -- /* * Tim Bissell ... the six million donald man ... * donald@uk.ac.warwick * {..seismo}!mcvax!ukc!warwick!donald */