home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!mips!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!laphroaig!cflatter
- From: cflatter@nrao.edu (Chris Flatters)
- Newsgroups: comp.unix.bsd
- Subject: Re: Jolitz 386BSD-0.1 -- floating point perform
- Message-ID: <1992Jul22.152854.27730@nrao.edu>
- Date: 22 Jul 92 15:28:54 GMT
- References: <l6qc51INN1gu@neuro.usc.edu>
- Sender: news@nrao.edu
- Reply-To: cflatter@nrao.edu
- Organization: NRAO
- Lines: 22
-
- In article l6qc51INN1gu@neuro.usc.edu, merlin@neuro.usc.edu (merlin) writes:
- >I have most of the US Army BRLCAD three dimensional CSG modeling and
- >distributed ray tracing system ported to the Jolitz 386BSD-0.1. But,
- >I am getting only about one fifth of the floating point performance
- >previously measured using AT&T pcc and GNU gcc 1.4x on ATT UNIX SYSV.
- >
- >Does the compiler default to '387 emulation? Is there some flag which
- >needs to be set to actually use the coprocessor? Or are there reasons
- >386BSD-0.1 would exhibit relatively poor floating point performance?
-
- The problem is that there is a mismatch between gcc 1.4 and Intel coprocessors.
- gcc expects floating-point registers while the 80x87s have a stack. This
- leads to a fairly large performance hit. gcc 2.x can produce optimised code
- for the 80x87. Is anyone working on porting gcc 2.x to 386BSD? Come to
- think of it, is there anything that needs to be done to do this (wouldn't
- the BSD/386 configuration work)?
-
- NB: the coprocessor shows up as device psx0 during the bootstrap sequence. If
- this doesn't show up 386BSD thinks you don't have a coprocessor.
-
- Chris Flatters
- cflatter@nrao.edu
-