Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!spool.mu.edu!wupost!uwm.edu!ogicse!clark!serval!hlu From: hlu@eecs.wsu.edu (H.J. Lu) Newsgroups: comp.unix.bsd Subject: Re: How suitable is gcc-2.2.2 for 386bsd? Message-ID: <1992Nov1.195951.17838@serval.net.wsu.edu> Date: 1 Nov 92 19:59:51 GMT Article-I.D.: serval.1992Nov1.195951.17838 References: <1992Oct23.222805.24970@klaava.Helsinki.FI> <MEISSNER.92Nov1091311@curley.osf.org> Sender: news@serval.net.wsu.edu (USENET News System) Organization: School of EECS, Washington State University Lines: 49 In article <MEISSNER.92Nov1091311@curley.osf.org>, meissner@osf.org (Michael Meissner) writes: |> In article <1992Oct28.201437.16640@serval.net.wsu.edu> hlu@eecs.wsu.edu (H.J. Lu) writes: |> |> | In article <1992Oct28.135008.29265@ntuix.ntu.ac.sg>, eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes: [...] |> | |> |> | |> gcc-2.2.2 uses a different syntax from gcc-1.39 and it is still very volatile. |> | |> | I assume you are talking about `asm' syntax, not C syntax. |> |> I'm not aware of any non-upward compatible extensions, but there may |> be. We didn't have to change any of the asm's in OSF/1 in going from |> 1.39 to 2.2.2. If you used `asm' for 387, you may notice the changes. |> |> | |> : But there *IS* at least a couple of reasons for trouble with gcc-2.2.2 |> | |> : under 386bsd: |> | |> : - math support. gcc-2.2.2 generates many new 387-instructions relative |> | |> : to 1.39, and the bsd386 math-emulation may not be up to it (and I'm |> | |> : not putting it down: I wrote most of it, and I just recognize that |> | |> : it's not a piece of art. Linux no longer uses it). This will only |> | |> : get worse: gcc-2.3 will emit the fsin/fcos instructions directly. |> |> Unless you use -fno-builtin. How about -mno-ieee-fp? I heard that would just disable fsin/fcos but still use other very useful builtins. Without a 387, it is very hard to use ieee fp anyway. |> |> | |> : - gcc-2.x generates the 386 string instructions, and doesn't put a 'cld' |> | |> : before them, assuming that the direction flag is always cleared. If |> | |> : the kernel doesn't clear the direction flag at an interrupt or trap, |> | |> : you'll get weird behaviour. I don't think this is a problem for |> | |> : 386bsd, but I remember having problems with it under linux when |> | |> : testing out a pre-release of gcc-2.0. Easily fixed in any case. |> |> Yep, I fixed that in 2.3. Have you fixed the bug of non-optimized 386 code cross-compiled from Ultrix 4.2a (decstation 3100)? [...] H.J.