Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!usc!news
From: merlin@neuro.usc.edu (merlin)
Newsgroups: comp.unix.bsd
Subject: Re: Jolitz 386BSD-0.1 -- floating point perform problem code located?
Date: 23 Jul 1992 02:51:57 -0700
Organization: University of Southern California, Los Angeles, CA
Lines: 66
Sender: merlin@neuro.usc.edu (merlin)
Message-ID: <l6t09tINN4ue@neuro.usc.edu>
References: <l6qc51INN1gu@neuro.usc.edu> <1992Jul22.152854.27730@nrao.edu> <1992Jul23.010341.22292@klaava.Helsinki.FI>
NNTP-Posting-Host: neuro.usc.edu
------------------------------------------------------------------------------
I think I found the origin (or at least part of the origin) of the problem
with gcc compiled code using emulator instead of the available 80387 FPA.
In /sys/i386/isa/npx.c the system ignores the 80387 and sets itself to use
the emulator even though npxprobe() actually finds a valid 80387. What is
even stranger is that the emulator is REPEATEDLY turned on by some call to
npxinit() every time a new process is initiated from shell command line --
and very possibly whenever a new process is initiated. As a consequence,
386BSD is always using the emulator whether or not an 80387 is present.
The printf in the following file is repeatedly executed even though npxprobe
exits with a status = 1 (80387 found). This doesn't seem quite right to me.
I tried commenting out this code -- and I still ended up with emulator level
floating point performance -- so I suspect the emulator is also being turned
on elsewhere in the system. Perhaps someone could locate and suggest patch
to either eliminate the emulator -- or to only use the emulator when there
is no 80387 present in the system.
--------------------------------------------------------------------------
/* FROM: /sys/i386/isa/npx.c */
npxprobe(dvp)
/* insure EM bit off */
load_cr0(rcr0() & ~CR0_EM); /* stop emulating */
/* insure EM bit on */
load_cr0(rcr0() | CR0_EM); /* start emulating */
}
npxinit(control) {
load_cr0(rcr0() | CR0_EM); /* start emulating */
outb(0xb1,0); /* reset processor */
printf("\n npxinit: emulator turned on \n");
}
------------------------------------------------------------------------------
The problem does not seem to be in gcc 1.4x -- I am comparing 386BSD gcc 1.4x
with SCO SYSV/386 ODT 1.1 gcc 1.4x -- and 386BSD is much slower doing floating
point using the emulator than SCO is doing floating point using the 80387 FPA.
This seems to me to be a kernel problem -- not a gcc compiler problem.
This really needs to be fixed so we can get decent floating point performance
from the 80387 FPA whenever one is available. This would make it reasonable
to test and release the BRLCAD patches so people may obtain the original code
from the US Army and use it for mechanical design, 3D ray tracing, image and
signal analysis, and image display.
Thanks, AJ
------------------------------------------------------------------------------
Alexander-James Annala
Principal Investigator
Neuroscience Image Analysis Network
HEDCO Neuroscience Building, Fifth Floor
University of Southern California
University Park
Los Angeles, CA 90089-2520
Telephone: (213)740-3406
FAX: (213)746-2863
------------------------------------------------------------------------------