gcc on 3b1

[Alex S. Crain]

In article <182 at sendai.UUCP> rich at 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 at umbc3.umd.edu
alex at umbc3.umd.edu