Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!uunet!sun-barr!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!think.com!paperboy.osf.org!meissner From: meissner@osf.org (Michael Meissner) Subject: Re: How suitable is gcc-2.2.2 for 386bsd? In-Reply-To: hlu@eecs.wsu.edu's message of Wed, 28 Oct 92 20:14:37 GMT Message-ID: <MEISSNER.92Nov1091311@curley.osf.org> Lines: 60 Sender: news@osf.org (USENET News System) Organization: Open Software Foundation References: <1992Oct23.222805.24970@klaava.Helsinki.FI> <1992Oct28.135008.29265@ntuix.ntu.ac.sg> <1992Oct28.201437.16640@serval.net.wsu.edu> Date: Sun, 1 Nov 1992 14:13:15 GMT Lines: 60 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: | | [...] | | |> I've used gcc-2.2.2 to compile all utilities and some ported software like | |> bash, sc but it failed for petdingo, 386bsd kernel, f2c . | |> gcc-1.39 works for all these cases. If you do not have gcc-1.39 , | |> you'll not be able to have these software. | | FYI, gcc 2.2.2/2.3 can compile Linux kernel and f2c. And the OSF/1 kernel but that's neither here nor there. | |> | |> 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. | |> : 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. | |> : - 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. | |> : There should probably be no other major problems (although gcc-2.2.2 is | |> : a lot bigger than 1.39, so if you are tight on memory, 1.39 is much | |> : faster). One big note, if you configure gcc-2.2.2 or gcc-2.3.1 for a 486 rather than a 386 (or use the -m486 switch), the code generated will be about 10% bigger than if compiled for a 386. The main reason is that the 486 wants loop code aligned on a 16 byte boundary instead of a 4 byte boundary, and those alignment bytes take up space. Also, a second order effect is that the epilogue is 1 instruction greater, since the 486 leave instruction is slower than the two simple instructions it replaces. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 You are in a twisty little passage of standards, all conflicting.