Xref: utzoo unix-pc.general:839 comp.sys.att:3512
Path: utzoo!utgpu!water!watmath!uunet!lll-winken!lll-tis!ames!ncar!noao!arizona!naucse!rrr
From: rrr@naucse.UUCP (Bob Rose )
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: GNU C, GNU g++ & 2400 baud microcom
Message-ID: <735@naucse.UUCP>
Date: 17 Jun 88 22:02:53 GMT
References: <1118@unisec.usi.com> <1015@umbc3.UMD.EDU>
Organization: Northern Arizona University, Flagstaff, AZ
Lines: 38

In article <1015@umbc3.UMD.EDU>, alex@umbc3.UMD.EDU (Alex S. Crain) writes:
 > In article <1118@unisec.usi.com> dpw@unisec.usi.com (Darryl P. Wagoner) writes:
 > >Greetings,
 > >
 > >I have two questions, first what changes are need to get the gnu cc to
 > >working on the Unix PC? (ex: ld, shared library & config files).  I know
 > >this is a repeat issue but I didn't have a interest until I got g++.  BTW
 > >I have version 1.22 of GCC.
 > 
 > 	I ported gcc-1.18 to work on the unixpc, and was working on 1.22
 > until I found the last bug in the assembler and got so disgusted that I gave
 > up. It is my opinion that the unixpc assembler is too stupid to cope with
 > gcc past v1.18, although I think that some others are working on keeping things
 > up to date.

Its GNU time again :^)  First of all I have gcc-1.22 up and running and it does
*much* better than gcc-1.18. I will post the diff's to get it up in the
next few day's.

 > 	I will spend the summer (or less) porting gnu ld & as so that there 
 > will be a decent assembler for this box. In the meantime, I still have diffs
 > for gcc-1.18, and well send them out to anyone interested. 

Hey. If you get the assembler up we may get a real debugger on the 3b1.
Yes that is right. Have the assembler produce just a coef header (the first
dozen bytes or so it has the test data and bss size) but the rest of the
file like bsd. Then we can bring over the Gnu debugger. Am I sick or what?

 > BTW: I use gcc-1.18 as my default compiler because I find it superior to 
 > /bin/cc even without debugging support. (I will recompile w/ cc if I really
 > need sdb)

I'm not sure about this. The way gcc does an interger  multiply is gross!
(it calls a routine that calls a routine that does a multiply) This means
that even thou gcc produces such great code that when it does a library
function (integer mul, div, mod; floating point anything) You lose so
much time that the code it produces is slowing that cc. More on this
latter. Tonight I'll try to get the diff out for 1.22.
                                   -bob