mack@inco.UUCP (Dave Mack) (07/18/88)
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 */
Thanks in advance for any useful suggestions;
bill
Bill Hatch
Computational Engineering
(formerly Business and Technological Systems)
14504 Greenview Drive Suite 500
Laurel, Maryland 20708
(301)470-3839
uunet!bts!billdave@micropen (David F. Carlson) (07/19/88)
In article <2424@inco.UUCP>, mack@inco.UUCP (Dave Mack) writes: > 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 > Thanks in advance for any useful suggestions; > > Bill Hatch > Computational Engineering > uunet!bts!bill Bill, I have doing serious floating point math on the Microport 2.2 for 7 months. Your problem is unique. I suspect a corrupted binary: use sum(1) on /lib/comp. You should get the following: /lib/comp 24603 553 /lib/cpp 49828 28 /bin/cc 40893 30 If yours are different, check your dist disks. If they are different too, call uport and get a fixed disk. Disk IO errors, etc. can cause binary corruption. As far as floating point math, Microport does at this time support 80387 in hardware and software emulation. The 287 is supported in hardware only. What they are missing is the IEEE floating point exception handler code, which makes serious floating point and numerical analysis much more difficult. These are expected soon, but... -- David F. Carlson, Micropen, Inc. ...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave "The faster I go, the behinder I get." --Lewis Carroll
howardl@wb3ffv.UUCP (Howard Leadmon ) (07/20/88)
In article <2424@inco.UUCP>, mack@inco.UUCP (Dave Mack) writes: > > 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. Well first let me state that I have a WYSE-3216 80386 w/80287 machine that is running Microport V/386-2.2U for the OS, but DO NOT have DOS/Merge installed on the system. I also have 6meg RAM and 190meg disk, but I am sure this has no effect.. > 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. That is interesting news, I as I informed it had floating point support, but did not support the 1167 (no big deal to me). I am very glad to hear that they plan to start using the Green Hills C Compilier, as the benchmarks run on the standard compilier vs the Green Hills compiler, show the Green Hill compilier to be much more efficient (I'll take it...) > 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 */ > Well I ran the test both with and without optimization, and it compiled without a hitch. I also executed the compiled program, and as is should of done it reported nothing and exited back to my prompt... ------------------------------------------------------------------------------- UUCP/SMTP : howardl@wb3ffv | Howard D. Leadmon PACKET : WB3FFV @ W3ITM | Fast Computer Service, Inc. IP Address: 44.60.0.1 | P.O. Box 171 Telephone : (301)-335-2206 | Chase, MD 21027-0171
john@bby-bc.UUCP (john) (07/20/88)
In article <2424@inco.UUCP>, mack@inco.UUCP (Dave Mack) writes: > 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 I have seen this too - I took some code to a friends 386 system running Microport + Merge with 6mb (and a lot of other stuff too) and the compiler died every time I tried to compile floating point stuff. There were two different errors produced for the same piece of code with no discernible pattern as to their selection (i.e. multiple compile attempts with one of the two messages each time). Unfortunately I don't remember the messages now. The code had successfully compiled under Microport 286 and on various Suns. . . . > 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 would assume that unless stated otherwise they are currently supplying the AT&T compiler that is distributed with other 386 versions of Unix - it is hard to believe that there is no floating point support at all; some of the standard utilities output what look to be floating point numbers. The man page for cc had an option for forcing evaluation in single precision - doesn't sound like a system which should have no floating pont at all. It's also hard to believe anyone (Microport or AT&T) would deliver a Unix with no floating point support (note that I don't doubt what you relate) at all without warning the purchaser - how about someone at Microport (or AT&T or Bell Tech or Interactive) clearing up the status of float support??????? Please..... . . . > 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 ^^^^^^^^^^ see above comments john
bill@carpet.WLK.COM (Bill Kennedy) (07/23/88)
In article <293@bby-bc.UUCP> john@bby-bc.UUCP (john) writes: >In article <2424@inco.UUCP>, mack@inco.UUCP (Dave Mack) writes: >> 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 > >I have seen this too - I took some code to a friends 386 system running >Microport + Merge with 6mb (and a lot of other stuff too) and the ^^^^^ There is your culprit. I don't care what anyone says, Merge breaks important things. In proper perspective I gave up on V/386 + Merge a long time ago and pitched it into the street as (expensive) garbage. The chap I gave it to has not had a whimper out of it because he NEVER INSTALLED MERGE. Since DOS ability was prerequisite to my application I stand by my earlier remark, "I would not dignify it by calling it excrement", but if you remove the Merge component I must defer to the experience of the fellow who has it. He says it sleeps through the night and never cries or soils the linen. -- Bill Kennedy Internet: bill@ssbn.WLK.COM Usenet: { killer | att | rutgers | uunet!bigtex }!ssbn!bill
keith@uport.UUCP (Keith Hankin) (07/23/88)
Your floating point hangs with Microport System V/386 2.2 could be the result of several things. 1. The ALR machine may need special code to recognize the presence of the 80387 chip. The Compaq 20MHz machines need this code. It will be included with the next Microport release 3.0 (due out in September). 2. There is a known problem (Called Errata #21 by Intel) with the 80386 chip. If you are running in 386 protected mode (which UNIX always is) and you have a 80387 chip installed, if there is DMA going on (floppy, tape drive or smart serial card access), there is a possibility of random system hangs. This can be fixed by a piece of hardware made by Bell Technologies, which by the way, will not work with Compaq machines. 3. There are some bugs in old 80387 chips which would cause processes to hang. A simple awk script is available to test this problem. If you can break out of hanging processes by DEL, then it could be this problem. If it is a system-wide hang, then it is not this problem. Keith Hankin keith@uport Microport Systems
keith@uport.UUCP (Keith Hankin) (07/23/88)
> 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. > Microport 386 version 2.2 supports both the 80287 and 80387 chips AND emulation of their instruction sets if they do not exist in the computer. Version 3.0, to be released in September, will also include Green Hills C compiler in addition to the AT&T PCC compiler. It supports 80287, 80387 and Weitek 1167 math coprocessors, as well as 80287, 80387 and Weitek 1167 emulation. The Weitek emulation is not 100% complete, but it should suffice for the most common Weitek operations. Keith Hankin keith@uport Microport Systems -- Keith Hankin keith@uport Microport Systems
leein@uicsrd.csrd.uiuc.edu (07/23/88)
Again the 386-387 problem! I have seen this kind of help request so many times. Look up some magazine article on 'Intel 386 bug'. InfoWorld April 25 issue had an article with the title, "Intel Confirms 386 Bug Involving 32-Bit UNIX". It says: --------------------- ...a bug in the 80386 running 32-bit Unix in conjunction with an 80387 ... ... This problem occurs on the current B and C versions of 386 chip, and it will be fixed on the not-yet-shipping D version of the chip, according to Intel spokesperson Ursula Herrick. .... ... a " kluge card," which fits between the 386 chip and the motherboard. ... One version is sold by Ironwood electronics of St. Paul Minnesota, and cost $145 (part SX-PGA 132-01). Another version, the Math Adapter, is sold by Bell Technologies Inc.($195). ... ...Recent shipments from several 386 vendors have included the kluge cards on the motherboard. ... ...[About some related software problem] SCO has fixed the coprocessor present problem with its release 2.2.2 of XENIX 386. Interactive ..Release 1.06, and Microport .. Release 3.0. ---------------------------------- August Issue of Byte mentioned the problem in J. Pournelle's Chaos Manor. Anyway, that's too bad for those guys with such 386's. That's why I am still holding my money.
cam@ptisea.UUCP (Ghost of Cam) (07/25/88)
1. Check the 387 settings in cmos ram. 2. Check the ALR (Most aren't suitable for 123, ie 16MHZ parts running at 20MHZ) 3. Try running some dos programs that use the 387. Hope this helps -- Disclaimer: If employees dont represent an organization what does? Cameron Elliott Portable Cellular Communications Path: ...!uw-beaver!tikal!ptisea!cam
dar@belltec.UUCP (Dimitri Rotow) (07/30/88)
In article <371@uport.UUCP>, keith@uport.UUCP (Keith Hankin) writes: > Your floating point hangs with Microport System V/386 2.2 could be the > result of several things. ... > 2. There is a known problem (Called Errata #21 by Intel) with the 80386 > chip. If you are running in 386 protected mode (which UNIX always > is) and you have a 80387 chip installed, if there is DMA going > on (floppy, tape drive or smart serial card access), there is a > possibility of random system hangs. This can be fixed by a > piece of hardware made by Bell Technologies, which by the way, > will not work with Compaq machines. ... This is an inaccurate description of Erratum 21: it has nothing to do with DMA at all. Contact your local Intel sales office for a precise description of Erratum 21. Our Math Adaptor works just fine with Compaq. You can, by the way cure Erratum 21 in the operating system alone: UNIX System V Release 3.1 does just that in all clones with no need for retrofit hardware. - Dimitri Rotow
dar@belltec.UUCP (Dimitri Rotow) (08/08/88)
In article <387@uport.UUCP>, plocher@uport.UUCP (John Plocher) writes: > In article <248@belltec.UUCP> dar@belltec.UUCP (Dimitri Rotow) writes: > >In article <371@uport.UUCP>, keith@uport.UUCP (Keith Hankin) writes: > >> 2. There is a known problem (Called Errata #21 by Intel) with the 80386 > >... > >This is an inaccurate description of Erratum 21: it has nothing to do with > >DMA at all. > [ John quotes some folks on Erratum 21 ] > > "The problem occurs when four conditions are met simultaneously ... > The first condition is that demand paged virtual memory must be active. > The second is that the system must be using a DMA oriented peripheral ... > The third condition is that the system must have a 387 chip installed, > and in use, and the fourth is that the 80386 must be in a wait state." This is not a precise way to characterize the Erratum at all: that's why Intel publishes the precise, written descriptions to the length they do. DMA is not the culprit. If the 386 sees a hold request (for example, in *refresh* time, not just DMA or other phenomena), then one of the necessary conditions for Erratum 21 occurs. Note that memory refreshes happen almost continually (every 14 us or so) whereas by that reference scale DMAs occur at nearly geologic intervals. That's why it's so misleading to characterize the Erratum as being a DMA or system level peripheral problem ... it's pointing you in the wrong direction by three or more orders of magnitude. Note that the Erratum occurs with the *287* as well as a 387, and it can be turned on and off (machine architecture permitting) depending on how the uppermost address lines are set. The citation of "wait state" is misleading, since even a "zero wait state 386" will encounter Erratum 21 with pre D stepping 386 parts. > Granted, this is a bit different from the Official Intel Errata 21 publication > that you and I know so well, but if you think about it, the physical > conditions are similar. I appreciate the spirit, but to cite a subset manifestation of Erratum 21 as defining the problem can cause real difficulty among people trying to cope with it. After a year's experience with the issue, we see no reason to doubt the accuracy of Intel's publication. - Dimitri Rotow
james@bigtex.uucp (James Van Artsdalen) (08/10/88)
Liberally edited... In article <252@belltec.UUCP>, dar@belltec.UUCP (Dimitri Rotow) wrote: > DMA is not the culprit. If the 386 sees a hold request (for example, in > *refresh* time, not just DMA or other phenomena), then one of the necessary > conditions for Erratum 21 occurs. Note that memory refreshes happen almost > continually (every 14 us or so) whereas by that reference scale DMAs occur > at nearly geologic intervals. I hate to jump into a good flame war between vendors like this, but one must point out that refresh is usually done via DMA. Hence, DMA is done almost continuously on virtually all machines (PC's Ltd 386/16 being about the only exception I would guess). > The citation of "wait state" is > misleading, since even a "zero wait state 386" will encounter Erratum 21 > with pre D stepping 386 parts. How frequently? My 386 has no refresh cycles at all. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746