FP PROBLEM RESOLUTION

[Dave Mack]

The following problem description was posted on 7/18/88.  The problem
solution was received via uucp mail from Bill Greene.
I am posting the problem description and the (correct) solution in 
hope of saving time and money for other 80386/80387 Unix users. 

===================================
Floating Point Problem Description
===================================
Posted Monday, 7/18/88 in comp.unix.microport
HELP !!!

I have a problem with C compiler floating point operations under
Microport Unix 386 Version 2.2.  Any code that contains floating point
operations blows away both cc and lint.  In some cases this also locks
up the computer such that I have to reboot.  In other cases the "comp"
process spawned by cc just runs forever.  I dont think that this is
an 80387 problem because the crash happens during the compile or
lint phase rather than during execution.  There is no "core" file created
when I reboot or when I "kill -9" the comp process.

My version of Microport System V.3 is 2.2.  DOS Merge/386 and Streams are also
installed.  My system is an ALR 386/220 with the 80387 floating
point coprocessor, 2 MB of RAM, and a Seagate 80 Mb hard disk with
a Western Digital controller.

I took delivery of this system with the Microport operating system
on May 28, 1988 from Advanced System Concepts of Arlington, Va.
I reported this floating point problem to Microport (with examples 
on floppy disk) on 6/21/88.  Microport technical support acknowledged 
receipt on 6/24 and have responded that they were unable to duplicate 
my results.   On 7/14 I contacted the Microport sales with some related
questions on their next release.  I was told that Version 2.2 does not
include either 80387 support or 80387 emulation (i.e. no floating point
support); however, the next release scheduled about August 1 will 
include these features in addition to the Green Hills C compiler.

I am still communicating with Microport on this problem and the 
possible information discrepency between their sales and tech support.

This is not an attempt to complain about Microport.  I feel that they 
provided me with a reasonable System V.3 port; however, I am posting 
this in hopes that someone else has encountered simular problems,
isolated the cause and discovered a workaround.

Please mail your responses to "uunet!bts!bill".  I will summarize and
post the results.  

A typical code segment that causes "comp" to run forever on "cc -c test.c"
follows:

/* test.c */

main()
{
	float x,y,z;
	z = 2.0;
	x = 3.0;
	y = x * z;
}
/* end test.c */

================================
FP SOLUTION FROM BILL GEREENE
================================

>From uucp Mon Jul 18 18:13 EDT 1988
>From csmunix.larc.nasa.gov!whg  Mon Jul 18 14:57:37 1988 remote from uunet
To: bill%bts.uucp
Subject: Floating point problems

Bill,

I felt a certain deja vu reading your recent posting. I experienced a
similar problem running cc on System V/386 and nearly pulled my hair out
trying to understand it. I also sent a copy of my C program to Microport
and they were unable to reproduce the problem. The problem is in fact the
Eratum 21 (386/387/paging) bug. I know it seems a little strange that the
compiler is executing floating point instructions, but it does seem to be.
The symptoms you observe are identical to what I experienced. You can verify
that the problem is Eratum 21 by simply removing the 387 and doing your 
compile or you can just get one of the math adapter boards from Bell Tech.
I think its overpriced at $ 145.00 but it does work. Good luck.

                          Bill Greene

=======================================
ADDITIONAL INFORMATION FROM BILL GREENE
=======================================
>From uucp Tue Jul 19 09:01 EDT 1988
>From csmunix.larc.nasa.gov!whg  Mon Jul 18 22:43:11 1988 remote from uunet
To: bill%bts.uucp
Subject: More on Erratum 21

Bill,

     Erratum 21 is an occasionally discussed bug in the 80386 that occurs
sometimes during floating point operations when paging is also occuring.
Intel has said that they have plans to fix this bug but I'm not sure if
that has happened yet. Some motherboard manufacturers (but not yours
or mine) have included circuitry on the board to work around the problem.
I think maybe the Compaq 386/20 is immune from this problem. As an alternative
Bell Technologies has been selling something they call the 386 Math Adapter
which will also cure the problem. It is just a small daughter board that
has a 386 socket and a single PAL on it. You just unplug your 386, plug
in the math adapter, and then plug the 386 back in on top. As I mentioned,
the price for all this hardware is $ 145.00. I've heard there is also another
company selling a similar product but I can't remember the name. Anyway, the
number for Bell Tech, if you don't have it handy, is 800-FOR-UNIX. Supposedly
they have slightly different configurations of this board to better fit your
particular motherboard. I mention this because the one I have is a very
tight fit in my box and one oriented 90 degrees would be a big help.

     Anyway, glad you resolved your problem. I struggled with it for several
months and know how frustrating it can be. I'm very surprised with how little
discussion there is on the net about this problem. I guess most 386 Unix
users aren't using 387's. I posted an enquiry about a month ago soliciting
people's experiences with both 387's and 1167's under Unix and got only
a couple of responses. Regards.

                           Bill Greene

PS: I believe Microport is actually using these Bell Tech boards in
some of their machines, which may be why they can't reproduce the
problem. Doesn't explain, however, why they can't just suggest a
remedy when the symptoms are so obvious.

===============
POSTED BY

Bill Hatch
Computational Engineering
(formerly Business and Technological Systems)
14504 Greenview Drive  Suite 500
Laurel, Maryland 20708
(301)470-3839
..uunet!bts!bill