alex@umbc3.UMD.EDU (Alex S. Crain) (01/28/88)
Okeedokay, the diffs for gcc went out today, after a great battle with an alian mailer. If you asked for them and don't get em, send mail. I tried to make sure that no one got two copies, and I think that I did ok, but if you did, sorry. Oh, yea, I fixed the bug in -O. -- :alex. alex@umbc3.umd.edu
rich@sendai.UUCP (K. Richard Magill) (03/26/88)
This deserves a little discussion. gcc HAS been ported to 3b1 BUT... It will be a LONG time before it is a replacement for the development set. First, gcc doesn't know COFF. gcc produces assembler which you must be assembled. Second, gcc comes with only runtime libraries. That is, only the libraries needed to make code produced with gcc run. This is fine for prom development, or if you have your own kernel and section 3, or if you're willing to use the devo set libraries. gcc is basically ansii. This means the old pcc bugs and quirks that most of us vets are used to are no longer there. Instead, ansii (more or less) replaces lint but introduces an entirely new set of quirks. Finally, while I support the GNU project whole-heartedly, (morally and financially, although seldom time wise), they don't really "care", as it were, about 3b1's. Meaning even the compiler bugs are YOUR problem if you use it. Pratically, 3b1 diffs have not yet made it into the gcc standard release. The gnu folks seem to work with vaxen and suns. This means that any 3b1 support distributed by FSF will probably lag 1-3 releases behind the "standard" gcc since the primary thrust is 68020. 68010 code generation is considerably less tested than 68020 and SysV (or SysV-esque environs like 3b1) are hostile territory to much of gnu. If you want good tools, get bison, get gawk, get gnu make, get emacs. These all work beautifully on 3b1. (also get pdtar). xoxorich. ps, I use gnu-emacs constantly on all machines I work on. I use bison/gcc/gnu-make/gdb as my primary devo tool on sun3's. Think of emacs, bison, and gdb as production quality with gcc coming up quickly. g++, make, gnu-ld, are really in pretty early stages of development. I haven't used gas enough to judge.
alex@umbc3.UMD.EDU (Alex S. Crain) (03/26/88)
In article <182@sendai.UUCP> rich@sendai.UUCP writes: >This deserves a little discussion. gcc HAS been ported to 3b1 BUT... > >It will be a LONG time before it is a replacement for the development >set. First, gcc doesn't know COFF. gcc produces assembler which you >must be assembled. Second, gcc comes with only runtime libraries. >That is, only the libraries needed to make code produced with gcc run. gcc is only a compiler, and will never replace the development set. It can, however, replace /bin/cc, /lib/ccom, /lib/cpp, and /lib/optim. gcc can get along with /bin/as just fine. /bin/cc doesn't know about COFF either, although it does know about sdb. >gcc is basically ansii. This means the old pcc bugs and quirks that >most of us vets are used to are no longer there. Instead, ansii (more >or less) replaces lint but introduces an entirely new set of quirks. Sorry, I don't miss the cc bugs one bit. And relying on pcc quirks is not generally considered good programming, especially since the general trend seems to be away from pcc and towards ansi. Besides, I've beat on gcc pretty hard, and I've haven't found any bugs so far, while I've found several in /bin/cc and I even managed to core dump the assembler! >Finally, while I support the GNU project whole-heartedly, (morally and >financially, although seldom time wise), they don't really "care", as >it were, about 3b1's. Meaning even the compiler bugs are YOUR problem >if you use it. I don't want to burst your bubble, but the only people who care about 3b1's are 3b1 owners. For example, this piece of code causes /bin/cc to generate illegal assembly code... /* illegal example */ void (* lookup ())(), foo(); main() { (*(lookup (foo)))("This is an argument"); } void (* lookup())() { return foo; } void foo (arg) char * arg; { puts (arg); } /* end of example */ The guy on the hotline agreed with us that this was a bug, and suggested that we not do this. he DID NOT fix this bug. he DID NOT suggest that he would EVER fix this bug. he DID imply that this bug WOULD NEVER BE FIXED. he also impiled that NO COMPILER BUGS would EVER be fixed. I got the same response when I demonstrated that /bin/as dumps core on long lines. Or that as does not recognise ~ (the current %pc value, often called ".") as legal syntax in an expression! There is no way to represent .+2 with the unixpc assembler, contrary to the documentation. The unixpc machine model is not that far from a sun running system V, which from a low-level standpoint is not as extream as it sounds. If a bug exists in gcc on a 3b1, it probably also exists on a sun with the -m68000 switch, so were not really alone. If you find a bug in gcc, report it. History dictates that it will probably be fixed in the next version. In fact, Ed Hepler already got a response for a bug in 1.15, before the port was complete. That makes the score gcc:1, at&t:0. >Pratically, 3b1 diffs have not yet made it into the gcc standard >release. The gnu folks seem to work with vaxen and suns. This means >that any 3b1 support distributed by FSF will probably lag 1-3 releases >behind the "standard" gcc since the primary thrust is 68020. 68010 >code generation is considerably less tested than 68020 and SysV (or >SysV-esque environs like 3b1) are hostile territory to much of gnu. Not true. I am currently corrisponding with Richard Stallman, and the dominant problem has been to coordinate the 3b1 support with the HPUX development that is currently progressing. If all goes well, both HPUX and 3b1 support will be included in the 1.20 release. (It's my fault that were not in 1.19, I had to shelve the project for a few weeks). With luck and sweat, either sdb support for gcc, or gdb support for COFF is on the horizon too. (I startled the former, but I've been buzy) >If you want good tools, get bison, get gawk, get gnu make, get emacs. >These all work beautifully on 3b1. (also get pdtar). True. But don't limit your horizons, either. >xoxorich. -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
alex@umbc3.UMD.EDU (Alex S. Crain) (03/31/88)
bug fix for gcc-1.18 diffs: Symptoms: Illegal assembly generated for character strings. Fix: The macro ASM_OUTPUT_ASCII is ifdefed out of tm-unixpc.h, this should be ifdefed back in again. ------------------------------------------------------------------------------ My copy works, Honest. -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu