tom@tandon.UUCP (Tom Friel) (02/06/90)
Although I watch this group carefully, I rarely venture into netland. I would hate to have this message generate 20 more postings. Anyway, these are my experiences with the FP problem. (I manage BIOS development for Tandon). We used to use AMI on our 386 motherboards, OEM'd from Mylex. In their very early .9 BIOS, they had a yes/no field in their setup screen for "Emulate Floating point?". This would simply turn on the EM bit of 386 register CR0. We put our own Tandon BIOS onto the Mylex last year (and still do). Along come some users who say they needed EM on! The major reason was that certain DOS applications (I particularly remember a DOS version of FGREP from someplace) would hang unless EM was set. Apparently, even though these applications worked fine on 286's, ther method of floating point detection didn't fly on 386's. So AMI put a field in setup; we tried to be cute instead. If someone got into the "hang" situation (FNINIT with EM set hangs, it's documented in the Intel 386 manual), we would trap in the BIOS and execute a recovery routine. Even though this wasn't great, at least the machine wouldn't hang. Our only Unix-es we had at the time to test were Xenix 286 and 386 (a problem since resolved!), which both worked fine. I should have known better than to trust all the DOS/BIOS guys around here. I really goofed by letting the "trap" scheme into the BIOS. This totally forgets about other environments, such as other Unix-es, PC-MOS, etc. etc. Thanks to Interactive, by the way. I went down to ISC in Santa Monica with my machine and BIOS, got a top-notch engineer onto a 386-ICE, and away we went. What we found was simply that ANY AT&T-based Unix would have the same problem: an FNINIT is issued, but the original AT&T-based kernel ASSUMED that the EM bit was 0. (If it was ON, it SHOULD HAVE BEEN cleared). So ISC gave me a small program to replace /etc/????/at386 (I forget the intermediate directory). All we did was add code to clear EM in this program, and away we went. I know that ISC, in 2.2 and forward, will have this problem corrected. But I still have to upgrade the BIOS in the field for SCO, PC-MOS, etc. We found another problem, too. In the 512-byte boot loader from AT&T, the register AX is cleared but EAX is referenced later. Due to the Tandon BIOS having a "sloppy" memory test, we had some leftover junk in EAX (among others), before boot. So I also fixed that in the BIOS upgrade. 512 bytes of code with an initialization bug! Moral to the story: I've got 5 years in Unix and love it. But don't hammer BIOS guys too hard (AMI, Award, Phoenix, us). From my point of view, both problems were caused by sloppy code inherited from AT&T. -- Tom Friel | Tandon Computer Corporation | (805) | tom@quad1.UUCP | 609 Science Drive Moorpark, CA 93021 | 378-7881 | tom@quad.com | Moorpark, CA 93021 |__________| UUCP: ..psivax!quad1!tandon!tom ..psivax!quad1!tom