tron1@tronsbox.xei.com (HIM) (12/19/90)
Ok, I am probably pushing my luck here ...
I have established from many people that a 80287 in the 80386 MB I have will
be fine, and that interactive will "do the right thing".
Now, there are two types of 80287 , the 80287-10 and the 80287-XL.
Since the 80287-XL claims a speed increase of like 400% over the 80287-10 I
looked it over and it said ...
"Caution: Do not use the 80287-XL in 80386 based computers.
Use only the 80287-10."
Wierd. So I called Intel and asked why.... the person there said that the
80287-XL was really a 80387 in a '287 carrier for the most part. It was much
faster because of this but that the 80386 CPU in my computer would wrongly
think it was a real 80387 and would just kinda stop dead. When asked, I was
assured that all the pins were compatible, and that no physical damage would
result from this un-holy union.
Now, the question.... many of the replies I got told me that the SysV math
code for using the math co-proc is really for the 80287 for compatibility
reasons. So this means that these are my questions...
1) Will it matter if the OS really did think it was a 80387 ? If it is
really only gonna generate 80287 code then....
2) My BIOS only has a 80287 on/off register, does ISC check the chips or the
to determin the FPU type ? (If the bios, then again, we will be ok).
3) Could a program with root priviledge go into the kernal and FORCE SET
the 80287 flag if the 8037 flag gets set wrongly ?
See the problem ??
(And they told me trying the Perstore under unix was bizzare!)
(Look ! No net!)
========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]=======
= The belief that by forcing one to be "Politically Correct" in speech =
= you can change what one thinks or feels, and so *CONTROL* the thoughts =
= and bend them to the patterns *YOU* wish is one that George Orwell =
= would have enjoyed seeing sweep the nation as it has, as predicted. =
=========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 ===================
= NONE of the opinions represented here are endorsed by either =
= Xanadu Enterprises or its clients, AT&T Bell Labs or others. =
=== The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====
dlau@mipos2.intel.com (Dan Lau) (12/20/90)
In article <276f6aae-1decomp.unix.sysv386@tronsbox.xei.com> tron1@tronsbox.xei.com (HIM) writes: > >Now, the question.... many of the replies I got told me that the SysV math >code for using the math co-proc is really for the 80287 for compatibility >reasons. So this means that these are my questions... The SysV math library code actually checks at run-time whether a 287 or 387 is available, and it will use the 387 instructions only if a 387 is installed (or the 387 emulator is being used). That was the way the code looked when Intel gave it back to AT&T, I don't know if the current versions are still the same. The standard pcc in SysV does not generate in-line math operations, so there is no question of compatibility there. Almost all third party 386 compilers will generate the 387 instructions directly for some of the math functions (like sin/cos, sqrt, etc.). The compilers are supposed to "assume" only a 287, unless there is a command line switch given (typically -f387). Speaking of the emulator, I know AT&T used to (still do?) ship two versions of the 387 emulator with SysV3.2+, do other vendors do it too? Are they both there on SVR4.0? Any comments on these two emulators, good or bad? Dan Lau Intel Corp.
tron1@tronsbox.xei.com (HIM) (12/20/90)
Ok.. for those that have followed this saga... After talking with INTEL/ISC here is what I did and what happened.. But first, a re-cap. I have the wierdo 386 from hell. A 16 MHZ NON-"EE" 386 motherboard that only has socket for a 80287 math co-proc. In addition, there is a Perstore controller compressing 2 st-506 hard drives, an ADAPTEC SCSI controller running a 80 MEG SCSI and a Archive tape drive. As if that isnt wierd enough, the only math co-proc I could get is a 80287XL .. this is actually a 80387SX in a 40 pin rectangular socket for '286's. So I put it in... the long and short of it is , it works!!!!! The small test program I have thinks it's a 80387, but X-windows and other floaters find it just fine and dandy... bizzare. ========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]======= = The belief that by forcing one to be "Politically Correct" in speech = = you can change what one thinks or feels, and so *CONTROL* the thoughts = = and bend them to the patterns *YOU* wish is one that George Orwell = = would have enjoyed seeing sweep the nation as it has, as predicted. = =========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 =================== = NONE of the opinions represented here are endorsed by either = = Xanadu Enterprises or its clients, AT&T Bell Labs or others. = === The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====
sef@kithrup.COM (Sean Eric Fagan) (12/20/90)
In article <276f6aae-1decomp.unix.sysv386@tronsbox.xei.com> tron1@tronsbox.xei.com (HIM) writes: >Now, the question.... many of the replies I got told me that the SysV math >code for using the math co-proc is really for the 80287 for compatibility >reasons. So this means that these are my questions... Actually, if I remember correctly, they are both '287 and '387. The code determines what kind of fpu is available, and chooses which code to use. (Note: this is how SCO does things; I may be confusing the SCO devsys with the stock 3.2 devsys. Sorry if I'm wrong...) >1) Will it matter if the OS really did think it was a 80387 ? If it is > really only gonna generate 80287 code then.... I suspect the problem is that the *386* gets confused. If it expects certain signals to come from the FPU, and the FPU doesn't have the capability of generating said signals, then the chip will just... wait. >2) My BIOS only has a 80287 on/off register, does ISC check the chips or the > to determin the FPU type ? (If the bios, then again, we will be ok). No, I think it queries the FPU itself. If there isn't one, then the operation will fail, and the OS knows to use the emulator. If it doesn't fail, it can get the FPU type from the FPU. >3) Could a program with root priviledge go into the kernal and FORCE SET > the 80287 flag if the 8037 flag gets set wrongly ? Ugh... you *could*, by writing to /dev/kmem, but I don't know if you want to. If the machine actually boots and gets to the OS, I suspect you won't run into any problems. But you'd have to try it, I guess... -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
john@jwt.UUCP (John Temples) (12/21/90)
In article <1486@inews.intel.com> dlau@mipos2.UUCP (Dan Lau) writes: >The SysV math library code actually checks at run-time whether a 287 or >387 is available, and it will use the 387 instructions only if a 387 is >installed (or the 387 emulator is being used). That was the way the code >looked when Intel gave it back to AT&T, I don't know if the current >versions are still the same. I extracted sin.o from /lib/libm.a, disassembled it, and sure enough, there was an fsin instruction in there. (Unfortunately, "dis" barfed on it -- it doesn't seem to understand the 387-only instructions.) I checked this on ESIX-D, Microport 2.2, and ISC 2.0.2 -- they all had it. >The standard pcc in SysV does not generate >in-line math operations, so there is no question of compatibility there. >Almost all third party 386 compilers will generate the 387 instructions >directly for some of the math functions (like sin/cos, sqrt, etc.). The >compilers are supposed to "assume" only a 287 I remember running the "savage" benchmark (transcendental-intensive) on a 387-equipped machine, compiling with both cc and Green Hills gcc a couple years ago. The gcc-compiled binary (with -f387x) was so much faster than the cc binary that I assumed libm.a was 287-only. It's surprising that using inline instructions would be so much faster than calling a procedure using the same instructions. >Speaking of the emulator, I know AT&T used to (still do?) ship two versions >of the 387 emulator with SysV3.2+, do other vendors do it too? ESIX has both emulators. The release notes say that the default emulator doesn't do the 387-only instructions, but runs much faster. But code with 387-only instructions will get a floating point exception with the default emulator. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)