hope@gatech.CSNET (Theodore Hope) (01/11/86)
I recently unpacked and brought up a 3b2/400, which supposedly comes with the
WECO 32??? math chip. Just to see how fast (or slow) the fp hardware is, I
wrote a 4 line program, compiled it WITHOUT the infamous '-f' option, and got
an Illegal Instruction trap. When compiled WITH '-f,' the program worked.
Here's the catch: Since we didn't buy the Software Generation utilities
(cc, as, ld, etc,) I moved them over from a 3b2/300 (no math chip). Is it so
that there is a special 'as' and/or special libraries which take care of the fp handling? I don't think so, since all fp traps should be handled in a software-
transparent fashion (cpu traps, hands off math instruction to the math chip,
gets result back, keeps going...) Or does the machine not come with the math
chip as standard equipment? What's the scoop?
(BTW, here's the prog:
float x, y;
main ()
{
x = 3.14159;
y = x + 2.432;
}
)
Any insight or useful comments will be appreciated.
--
Theodore Hope
School of Information & Computer Science, Georgia Tech, Atlanta GA 30332
CSNet: hope@gatech ARPA: Hope%GATech.CSNet @ CSNet-Relay.ARPA
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-sally}!gatech!hopewan@gatech.CSNET (Peter N. Wan) (01/12/86)
Ted,
There is another compiler package that is needed on the 3B2/400 to
take advantage of the floating point hardware (the math chip is
optional, I may add). If you bring over the one from a 3B2/300, you
still have to use the "-f" to properly process floating point stuff.
Look at your owner's manual; I believe that is where they tell you
about the new compiler package (is it available yet?).
Peter
P.S.
Anyone know if the 3B2/400 is out of "controlled introduction" yet?
--
Peter N Wan
UUCP : ...!{akgua,allegra,ihnp4,rlgvax,ut-ngp,ut-sally}!gatech!wan
ARPA : Wan%GaTech.CSNet@CSNet-Relay.Arpa CSNET : Wan@GaTechwcs@ho95e.UUCP (#Bill.Stewart.2G202.x0705) (01/12/86)
In article <2403@gatech.CSNET> hope@gatech.CSNET (Theodore Hope) writes: >I recently unpacked and brought up a 3b2/400, which supposedly comes with the >WECO 32??? math chip. The 32106 Math Acceleration Unit (floating point chip) is optional; if you don't order it you don't get it. > Just to see how fast (or slow) the fp hardware is, I >wrote a 4 line program, compiled it WITHOUT the infamous '-f' option, and got >an Illegal Instruction trap. When compiled WITH '-f,' the program worked. >Here's the catch: Since we didn't buy the Software Generation utilities >(cc, as, ld, etc,) I moved them over from a 3b2/300 (no math chip). The SGS for the 400 is new. If you had the original 3B2/300 SGS, you really don't want to use it for floating point anyway; it was a dog. Get the new stuff. (The software licensing agreements are also much clearer when you buy the software.) Disclaimer: I'm speaking as an individual, and this posting is not a statement of policy by AT&T or its subsidiaries. (But they'd still like you to buy the new stuff, and the old FP really *was* a dog :~). -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
heiby@cuae2.UUCP (Heiby) (01/13/86)
There have been several C Compilation Systems (Software Generation Systems)
for the 3B2. Issue 1 was released with the first release of UNIX for the
3B2. Issue 2 was released with SVR2. Issue 2 contains a method for floating
point arithmetic software routines. This works by putting "illegal"
instructions into the instruction stream. When the cpu attempts to execute
the instruction, it traps on it. If the program had been compiled with the
"-f" option, there is a set of floating point emulation routines that are
called to perform the operation. Issue 2 has no knowledge of the Math
Accelleration Unit (MAU).
With the introduction of the MAU, there is a new version of the CCS available
called Issue 3 (3.1 is current). The "-f" option (if accepted at all) does
nothing in this issue. All floating point operations are executed by function
calls (avoiding the trap overhead). The first time the floating point
functions are called, they determine whether or not a MAU is present. If it
is, then all floating point operations are executed via MAU instructions. If
it is not, then the software emulation routines are executed. Even without
the MAU, the performance improvement can be substantial (without the trap
and context switching overhead). This compiler will compile on any 3B2
system (SVR2 or later) with or without a MAU. The generated executables
will run on any 3B2 system (SVR2 or later) with or without a MAU. You will
just see different floating point performance in the generated executables.
(My information is that the CCS uses no floating point internally.)
Available most recently is "C-FP+", which executes floating point operations
via in-line MAU instructions. This saves the function-call overhead and
a bit of testing the "MAU-present" flag. I've heard that FP operations
really fly when compiled with this compiler. For heavy floating point users
this may well be worth getting. The drawback is that the generated executables
MUST run on a system with a MAU chip if they do any floating point.
In general, as new features are introduced in AT&T hardware or in the UNIX
operating system, there will be new CCS issues as needed to support those
new features. Whenever SVR3 is announced, there will be a new CCS to support
those of its new features that require CCS support. The current (Issue 3)
CCS will continue to operate correctly, but will not provide access to
those new capabilities as the new CCS will. (The contents of /usr/include/sys
are also updated to match the new UNIX release.)
--
Ron Heiby {NAC|ihnp4}!cuae2!heiby Moderator: mod.newprod & mod.os.unix
AT&T-IS, /app/eng, Lisle, IL (312) 810-6109
"It's Astounding! Time is fleeting! Madness takes its toll!"sherm@poseidon.UUCP (Paul A. Sherman) (01/24/86)
In article <1735@cuae2.UUCP> heiby@cuae2.UUCP (Heiby) writes: >With the introduction of the MAU, there is a new version of the CCS available >called Issue 3 (3.1 is current). The "-f" option (if accepted at all) does >nothing in this issue. All floating point operations are executed by function >calls (avoiding the trap overhead). The rest of Ron's article is quite accurate, but the Issue 3 (3.0 and 3.1) CCS's DO accept and act upon the "-f" option for backward compatability reasons. The "-f" flag works the same way as it has in previous releases of the CCS. It causes a special version of the runtime startup routine (/lib/fcrt0.o instead of /lib/crt0.o) to be linked in. This file sets up the traps that Ron discussed and causes the code in fptrap.o (from libc.a) to be included in the a.out. For programs compiled from scratch with Issue 3 this flag is indeed unnecessary and just causes larger code. However, if you have any object modules (e.g. archive libraries) that contain floating point and were built with previous releases of the CCS, linking them requires the floating point trap. Without it the (still illegal) floating point opcodes contained within will cause a core dump at run time. Building with the "-f" flag to the Issue 3 CCS doesn't slow down floating point operation on new code. It still uses function calls for floating point operation and they use the MAU if it exists. It does allow old binary modules to be linked in and perform (still high overhead) floating point operations. This flag becomes necessary if you are trying to link against vendor distributed libraries that were built before Issue 3 of the CCS was available. By the way, Issue 4 of the CCS (for System V Release 3) continues this same behaviour. I haven't seen C-FP+ so I don't know whether it allows this sort of backward compatability or not. -- Paul Sherman AT&T Information Systems, Lincroft, NJ {pegasus!phoenix}!poseidon!sherm (201) 576-6316