dpw@unisec.usi.com (Darryl P. Wagoner) (06/08/88)
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.
Second, flow control on rs-232 port. I am using a Microcom 2400 and would
like to kept the baud rate at 2400. Is that possible on the Unix-PC and
if so how?
--
Darryl Wagoner dpw@unisec.usi.com
UniSecure Systems, Inc.; OS/2, Just say No!
Round Rock, Tx; (512)-255-8751 (home) (512)-823-3774
UUCP: {ut-sally!uiucuxc!kitty}!unisec!dpwalex@umbc3.UMD.EDU (Alex S. Crain) (06/14/88)
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. 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. 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) -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
ford@elgar.UUCP (Mike "Ford" Ditto) (06/17/88)
In article <1118@unisec.usi.com> dpw@unisec.usi.com (Darryl P. Wagoner) writes: >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 remember someone else saying they were working on gcc for the Unix PC, but I went ahead and started working on it anyway. I have gcc version 1.19 running on the Unix PC. It generates SGS assembler code, suitable for assembly with "/bin/as" and linking with "/bin/ld". It is compatible with the standard libraries. Although I haven't tried using the shared library, it should work fine. I have been primarily using it for cross development to a 68020 system, and therefore I have also ported and tested all the 68020 and 68881 code generation, which are command-line options. I also made gcc support the CENVIRON environment variable in the same way that the Unix PC assembler and linker do, allowing easy '020 and '881 development. The only real problem I encountered was that the Unix PC assembler can't handle a relative-address switch table in the format gcc puts it out, and gcc can't handle non-relative switch tables (the docs say it can, but it dumps core). I kludged around this by making gcc always choose to use skip chains (a compare & jump sequence for each case), which is not as efficient but required the smallest change to the compiler source code. I will be getting a newer version of gcc and putting together the diffs needed for the Unix PC. I'll let the world know when it's ready. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads
alex@umbc3.UMD.EDU (Alex S. Crain) (06/17/88)
>I will be getting a newer version of gcc and putting together the diffs >needed for the Unix PC. I'll let the world know when it's ready. Its ready. I found the bugs in 1.22 and fixed them, and sent the fixes off to mit today, so hopefully 1.23 will install itself. The fixes were small (a dozen lines or so) and localized (1 typo, and a mod to the switch table code), so the chances of a smooth build are very high with the new veersion. Note that gcc will require gnu-cpp to compile, as the code breaks the 3b1 /lib/cpp. Also note that sdb is not supported in any way (but adb works just fine :-)) I can supply a uuenoded cpp and/or the diffs to make 1.22 work if anyone is interested, I will post them it the demand is high enough. > -=] Ford [=- > >"Once there were parking lots, (In Real Life: Mike Ditto) >now it's a peaceful oasis. ford%kenobi@crash.CTS.COM >This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford >now it's all covered with daisies." -- Talking Heads -- :alex. nerwin!alex@umbc3.umd.edu alex@umbc3.umd.edu
rrr@naucse.UUCP (Bob Rose ) (06/18/88)
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