Math Coprocessors

Math Coprocessors

Post by Pete Holsbe » Tue, 13 Nov 1990 12:25:26



The question came up recently as to whether or not a math coprocessor
would be a useful addition to a UNIX computer system.  One of us said
that it would not unless the programs that were being run used floating
point and/or extended integer arithmetic.  The other said that one will
find relatively few programs which do not do at least SOME floating
point or extended integer math, even if it is not explicitly present in
the program it may be present in a library routine.

Inquiring minds would like to know who is closest to the truth.  Let us
limit the discussion to UNIX systems running with CPUs that do not have
math coprocessors built-in, if you don't mind.

Thanks,
Pete
--
Prof. Peter J. Holsberg      Mercer County Community College
Voice: 609-586-4800          Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh  1200 Old Trenton Road, Trenton, NJ 08690

 
 
 

Math Coprocessors

Post by Doug Gw » Tue, 13 Nov 1990 23:32:25



>The question came up recently as to whether or not a math coprocessor
>would be a useful addition to a UNIX computer system.  One of us said
>that it would not unless the programs that were being run used floating
>point and/or extended integer arithmetic.  The other said that one will
>find relatively few programs which do not do at least SOME floating
>point or extended integer math, even if it is not explicitly present in
>the program it may be present in a library routine.

If the math coprocessor runs asynchronously, the kernel may require some
subtle hackery to properly context switch.  I ran into this when adapting
Sixth Edition UNIX for use on a PDP-11/34 with FPU.  (Fortunately, for
the most part I was able to borrow the FPU support code from the PDP-11/45
version.)  Even with math coprocessor hardware, you still need for the
compilers to generate floating-point instructions.  Most often they will
simply generate calls to run-time library arithmetic support routines,
which are implemented using the basic integer instruction set.  Then, you
need to be aware that any code that uses FP instructions and is copied to
a system that does not have the FP hardware is going to generate
exceptions; whether or not the kernel attempts to emulate the FP
operations or simple posts a SIGFPE to the process, the results will be
rather miserable.

As to how much FP hardware will help a typical application, the answer is
that it of course depends on the application.  Most "system" software
will be essentially unaffected by the availability of FP hardware.  A few
engineering-style, and some graphics, applications can speed up noticably
using FP hardware.  I would say that unless you have identified a
particular bottleneck application that heavily uses floating point,
you'd be wasting your money to buy an FPP.

 
 
 

Math Coprocessors

Post by Peter Brouw » Wed, 14 Nov 1990 16:28:28



Quote:>The question came up recently as to whether or not a math coprocessor
>would be a useful addition to a UNIX computer system.  One of us said
>that it would not unless the programs that were being run used floating
>point and/or extended integer arithmetic.  The other said that one will
>find relatively few programs which do not do at least SOME floating
>point or extended integer math, even if it is not explicitly present in
>the program it may be present in a library routine.

Awk uses floatig point a lot. I think most programs don't use float arithmetic.

If your source does not contain float or double type variables ( or not in hot
places ) your not using float arithmatic. I think there are not many C library
functions who are using float arithmetic.

--
#  Peter Brouwer,                | Philips Information Systems,                #

#  UUCP : ....!mcsun!philapd!pb  | P.O.Box 245,7300AE Apeldoorn,The Netherlands#
#  PHONE:ext [+31] [0]55 432992, | FAX  :ext [+31] [0]55 433488                #

 
 
 

Math Coprocessors

Post by Larry Wa » Thu, 15 Nov 1990 01:29:03


: Awk uses floatig point a lot. I think most programs don't use float arithmetic.

Perl uses floating point a lot too.

Larry Wall

 
 
 

Math Coprocessors

Post by Alan H. Min » Thu, 15 Nov 1990 09:03:53



> The question came up recently as to whether or not a math coprocessor
> would be a useful addition to a UNIX computer system.  One of us said
> that it would not unless the programs that were being run used floating
> point and/or extended integer arithmetic.  The other said that one will
> find relatively few programs which do not do at least SOME floating
> point or extended integer math, even if it is not explicitly present in
> the program it may be present in a library routine.

The SCO XENIX 386 O/S definitely makes use of the FPU if it is available
(according to SCO). I'll try and run some benchmarks with/without in a couple
days, but it definitely "feels" faster.

Most SCO applications will use FPU's also. Some Foxbase+ results:

Task                            time/without    time/with

Video Speed                     20              20
Tight Loop                      52              20
File Creation                   26              20
Small Record Processing         77              20
Large Record Processing         64              20
Text Export/Import              20              20
Simple Math                     48              20
Complex Math                    176             20

--
< Alan H. Mintz             | Voice +1 714 980 1034 >
< Micro-Quick Systems, Inc. | FAX   +1 714 944 3995 >
< 10384 Hillside Road       | ...!uunet!mq!alan     >

 
 
 

Math Coprocessors

Post by Sean Fag » Fri, 16 Nov 1990 07:08:35



>Perl uses floating point a lot too.

So, Larry, when are you going to write you FP-emulator in perl?
Is that going to be before or after the OS in perl?

--
-----------------+
Sean Eric Fagan  | "*Never* knock on Death's door:  ring the bell and

uunet!sco!seanf  |     -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor")
(408) 458-1422   | Any opinions expressed are my own, not my employers'.

 
 
 

Math Coprocessors

Post by Sean Fag » Fri, 16 Nov 1990 07:11:19



Quote:>The SCO XENIX 386 O/S definitely makes use of the FPU if it is available
>(according to SCO).

The kernel does not use floating point.

All SCO systems (for the '286 and later) can assume that there is a subset
of an 8087 available, as we ship an FP emulator with the OS.  (The reason
the kernel doesn't use floating point is because, if there were no FPU
present, bad things would happen during the trap to the emulator.)

--
-----------------+
Sean Eric Fagan  | "*Never* knock on Death's door:  ring the bell and

uunet!sco!seanf  |     -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor")
(408) 458-1422   | Any opinions expressed are my own, not my employers'.

 
 
 

Math Coprocessors

Post by Pete Holsbe » Sat, 17 Nov 1990 03:46:07



=The SCO XENIX 386 O/S definitely makes use of the FPU if it is available
=(according to SCO).

        Do they say in what way the OS uses it?

=I'll try and run some benchmarks with/without in a couple
=days, but it definitely "feels" faster.

        I'd love to see the results.
=
=Most SCO applications will use FPU's also. Some Foxbase+ results:
=
=Task                           time/without    time/with
=
=Video Speed                    20              20
=Tight Loop                     52              20
=File Creation                  26              20
=Small Record Processing                77              20
=Large Record Processing                64              20
=Text Export/Import             20              20
=Simple Math                    48              20
=Complex Math                   176             20

        That column of 20s makes me sceptical!

Pete

--
Prof. Peter J. Holsberg      Mercer County Community College
Voice: 609-586-4800          Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh  1200 Old Trenton Road, Trenton, NJ 08690

 
 
 

Math Coprocessors

Post by W. Paul Zo » Wed, 21 Nov 1990 23:46:59




>=The SCO XENIX 386 O/S definitely makes use of the FPU if it is available
>=(according to SCO).

>    Do they say in what way the OS uses it?

[deleted]

There has been a great deal of confusion about this.  To put it
as clearly as possible:  the SCO XENIX *kernel* and the SCO UNIX
*kernel* do NOT use floating-point calculations.  Since they don't
use floating-point calculations, they don't use the FPU, even if
one is present.

What the SCO kernels do provide is a means by which application
programs can use the FPU if one is present.  The access to the FPU
is transparent to the application: applications always "see" an FPU
present, and always use the FPU instructions.  It is the kernel's
job to hand off the FP instructions to the co-processor chip (if one
is present) or to emulate the FP instruction (if there is no FPU
present or if the kernel was instructed to ignore the FPU via the
'ignorefpu' boot string directive).

In summary:
    If an application uses floating-point instructions and an FPU
    is present, then the kernel will make sure the application
    uses the FPU.

    If an application uses floating-point instructions and an FPU
    is not present, then the kernel will emulate the FPU on behalf
    of the application.

    In no case does the kernel itself use floating-point instructions
    or the FPU.

I hope this clarifies things for people.

-
Paul Zola                       Software Support Engineer

We only know in theory what we are doing.   - Kate Bush
    DISCLAIMER: I speak for myself, and not for SCO.

 
 
 

Math Coprocessors

Post by Gordon Burdi » Wed, 28 Nov 1990 07:52:28


Quote:>    If an application uses floating-point instructions and an FPU
>    is present, then the kernel will make sure the application
>    uses the FPU.
>    If an application uses floating-point instructions and an FPU
>    is not present, then the kernel will emulate the FPU on behalf
>    of the application.
>    In no case does the kernel itself use floating-point instructions
>    or the FPU.

How, then, is it arranged that process A and process B, both of which use
floating point, don't stomp all over each other's FPU registers?  It would
seem that the kernel must minimally load and unload the FPU state when
necessary due to process switches between processes using the FPU.

If it doesn't use any floating-point instructions, how does it figure out
whether the FPU is present?

                                        Gordon L. Burditt
                                        sneaky.lonestar.org!gordon

 
 
 

Math Coprocessors

Post by Lyle Seam » Thu, 13 Dec 1990 08:00:15



>How, then, is it arranged that process A and process B, both of which use
>floating point, don't stomp all over each other's FPU registers?  It would
>seem that the kernel must minimally load and unload the FPU state when
>necessary due to process switches between processes using the FPU.

It's probably because the kernel is non-preemptable, so the FP operation
runs to completion before the process switch.

Quote:>If it doesn't use any floating-point instructions, how does it figure out
>whether the FPU is present?

Does it matter?

--

508 967 2322         Lowell, MA, USA       uunet!comm.wang.com!lws
             The scum always rises to the top.

 
 
 

1. Linux and Math Coprocessor

I have just acquired a 40mhz 386DX tower with the intention of installing
Linux in the near future.  The system will have 8 meg ram and around a 300
meg hard drive.

It currently has an empty 80387 socket.  

My question is whether or not adding an 80387 will result in noticable
performance increases running Linux?  If so, it'll move up on my long
priority list of desired purchases.

Thanks!

Tony
--

------------------------------------------------------------------------------

2. rquotad question...

3. make says error 136 (caused by math coprocessor???)

4. Digital Video: convert AVI to QuickTime, editing software

5. Math coprocessor problem?

6. Radio NON-STOP App.

7. Do I need a math coprocessor

8. Windows NT RAS and Linux

9. Math coprocessor error? help!

10. Math Coprocessor problem - Linux won't boot

11. Math Coprocessor

12. Math coprocessor exception 16 error???

13. "No math coprocessor found" shown at boot-up