Floating Point-The Results Are In!
Steven M. Schultz
sms at moe.2bsd.com
Mon May 11 02:49:44 AEST 1998
> From: Johnny Billquist <bqt at Update.UU.SE>
> I wouldn't be *that* surprised by these results. For instance, I believe
> that longs are implemented with FP. And I wouldn't be surprised if a few
> FP ops were sneaked in to compute some stuff that aren't immediately
It is true that _some_ long arithmetic is done using FP. The long
divide is done that way (at least in 2BSD, I've not looked at V7 yet)
because it is much much less code to convert the operands to FP, do
the divide, and then convert the result back (the alternative is
about two pages of code). Different CPUs handle a fault during a
double word push to the stack differently, this was a real difficult
problem to track down and fix. If during the FP instruction
"movfi fr0,-(sp)" the stackpointer becomes invalid some PDP-11 CPUs
handle the fault differently. See 2.11BSD update #150 for the details.
The C compiler itself did NOT generate FP unless the operands were
explicitly FP (float or double). Most C code was 'int' or 'char *'
and no FP code was needed or used for that.
FP instructions would be clustered together where the libc.a routines
were loaded. The 'ldiv' and 'lrem' routines would have several FP
instructions close to each other but the rest of the program would
have very few. A program such as 'adb' would have a few FP instructions
in the routines that display the FP registers. Oh - there's a bug
dating back to V7 in adb. The FP registers for a traced/running
process do not display correctly (using adb on a core file works fine).
Fixed in 2.11 (see update #405) ;-)
Received: (from major at localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id GAA22952
for pups-liszt; Mon, 11 May 1998 06:42:17 +1000 (EST)
More information about the TUHS