Soft Float for PC386

angelo angelo at hunterlink.net.au
Thu Feb 8 01:57:34 UTC 2001


This is the current status:
I built and tested the PC386 build twice with msoft-float, once  with
-mno-fp-ret-in-387 and once
without -mno-fp-ret-in-387.  The PC is a 386DX with no coprocessor.  I
ran paranoia on the machine and
it failed with the exception 7.  Paranoia with this build also fails in
a pentium machine.  I suspected
that because the 386 machine was a DX, that the problem may have been
caused by the POPAD bug in that
model CPU.  I have changed my opinion as I have just tested the build on
the PC, this time I placed a
387 processor in it after you mentioned that exception 7 was no
co-processor found.  Paranoia still
fails, but not because of the exception 7, this time because the math
results fail.
The question is: "Why is the CPU looking for a co-processor with the
-msoft-float flags?"

In have also built the pc586 paranoia and ran it on a pentium machine.
It fails because of rounding
errors.
This should have nothing to do with the floating point libraries.



Joel Sherrill wrote:

> I have no idea what order these were posted in and what
> the current state is.
>
> I have sprinkled comments in this but it might be helpful if you
> posted a new summary status that we could work from.  I think
> you have (1) found a bug in gcc popa, (2) probably found a
> rounding difference between ix86 models, (3) found that
> the no-ret-in-fp is needed (and may also be needed on the
> soft-float libraries).
>
> --joel
>
> angelo wrote:
> >
> > angelo wrote:
> >
> > > If the problem was the POPAD error for the 386DX, that is something that I would probably have
> > > to find by building the development tools myself. However, the reason that paranoia fails on the
> > > pentium machine has nothing to do with alleged POPAD.  Who is providing the floating point
> > > libraries? Is it GCC?
>
> The soft-float libraries are provided by gcc if you are using the
> latest RTEMS tool RPMs.
>
> > >
> > > Erik Ivanenko wrote:
> > >
> > > > Sorry, but I can only point you in the ?right? direction.  I'm sure that
> > > > you could flag the build, but if the POPAD is in the gcc compiler, then
> > > > you have to modify the offending code there, and not in RTEMS, as I
> > > > suspect is the case.
>
> This particular case sounds like an instruction sequence that gcc should
> not
> have generated if the cpu isinfact selected to be an i386.  So my
> feeling is
> that if the selected CPU arguments are correct, this part is a compiler
> problem.
> That means it needs to be reported to the gcc bugs mailing list.
>
> > > >
> > > > Good luck.
> > > >
> > > > angelo wrote:
> > > > >
> > > > > It appears that there may be two different bugs rearing themselves in the same test.
> > > > > I built and ran the following program on both the 386DX and the Pentium machine using the
> > > > > pc386 soft float build
> > > > >
> > > > >   cout <<"test for standard float"<<endl;
> > > > >   float f;
> > > > >   cout <<"float has been declared. Now try some maths"<<endl;
> > > > >   f = 1.11111111 * 1.11111111;
> > > > >
> > > > >   cout <<"float Value :"<<f<<endl;
> > > > >
> > > > >   f = 0;
> > > > >   cout <<"float Value :"<<f<<endl;
> > > > >
> > > > >   cout <<"test for double"<<endl;
> > > > >   double d = 1.11111111 * 1.11111111;
> > > > >   cout <<"double Value :"<<d<<endl;
> > > > >
> > > > > I get two different reactions from each machine. The Pentium displays a rounding error
> > > > > from the double. This, I suspect is because the double may really only be a float, I'm not
> > > > > sure.
>
> paranoia is designed to find errors/variations of this sort so this is
> somewhat expected.
>
> > > > >
> > > > > The 386DX displays the exception after executing the line
> > > > >  f = 1.11111111 * 1.11111111;
> > > > >
> > > > > i.e. we see "float has been declared. Now try some maths" on the console.
> > > > >
> > > > > After doing some research and testing on this computer, I have discovered it has the POPAD
> > > > > fault, which is described as follows:
> > > > >
> > > > > POPA/POPAD bug
> > > > >      The bug is present in all 386DX chips and in early revisions of 386SX family models.
> > > > > If the POPAD instruction is followed by instruction using 32-bit indexed
> > > > >      addressing mode, EAX register content is not properly restored by POPA/POPAD
> > > > > instruction. The bug is very deterministic, so it can be used to differentiate
> > > > >      between Intel/AMD 386 and other similar processors.
> > > > > see the URL below.
> > > > >
> > > > > http://www.grafi.ii.pw.edu.pl/gbm/x86/3486bugs.html
> > > > >
> > > > > Are there any flags we can place in the build to correct these errors, if indeed this is
> > > > > the error?
> > > > >
> > > > > Erik Ivanenko wrote:
> > > > >
> > > > > > Sorry, can't help then.  The last time I ran paranoia was 2 years ago,
> > > > > > and I cannot run it now.
> > > > > >
> > > > > > angelo wrote:
> > > > > > >
> > > > > > > But the program also fails for the standard pc586 build, which does not use the soft
> > > > > > > floating point.  The error message is not the same, but significantly longer.
> > > > > > >
> > > > > > > Erik Ivanenko wrote:
> > > > > > >
> > > > > > > > iirc, what you have to do is add the software floating point libs to the
> > > > > > > > gnu C compiler. ( At least back in the gcc 2.8 days. )  I cannot
> > > > > > > > remember how to do this.  I did it for i386ex, and the ts-i386 had the
> > > > > > > > capacity.  At that time, GNU did not ship with soft FP for i386
> > > > > > > > enabled.  Bottom line was that the compiler needed to be rebuilt with
> > > > > > > > some changes.
>
> The new RTEMS RPMs include this support.  I have been working to get
> these submitted
> and officially merged into gcc.
>
> > > > > > > > Perhaps they were archived somewhere?
> > > > > > > >
> > > > > > > > angelo wrote:
> > > > > > > > >
> > > > > > > > > Successfully built and ran by modifying the following in pc386.cfg
> > > > > > > > >
> > > > > > > > > ifeq ($(RTEMS_CPU_MODEL),)
> > > > > > > > > RTEMS_CPU_MODEL=i386_nofp
> > > > > > > > > CPU_CFLAGS =-msoft-float
> > > > > > > > > endif
> > > > > > > > >
> > > > > > > > > I am not sure whether I should add the -mno-fp-ret-in-387 to the CPU_CFLAGS, I
> > > > > > > > > have tried both with the same result.
> > > > > > > > >
> > > > > > > > > The target now runs in the PC, however, when I attempt to run the paranoia.exe
> > > > > > > > > ,I get the following error message
> > > > > > > > >
> > > > > > > > > *** PARANOIA TEST***
> > > > > > > > > Exception 7 caught at PC 10743 by thread 13428265
> > > > > > > > > processor execution context at time of the fault was
> > > > > > > > > EAX = 0     EBX = 134300    ECX = 0    EDX = 0
> > > > > > > > > ESI = 13414    EDI = 12D878    EBP = 1342A8    ESP = 134268
> > > > > > > > >
> > > > > > > > > Error code pushed by processor itself (if not 0) = 0
> > > > > > > > > ****************   FAULTY THREAD WILL NOW BE DELETED ********************
> > > > > > > > >
> > > > > > > > > I then did a PC 586 build (even with an unmodified pc386.cfg) and tried to run
> > > > > > > > > paranoia on a Pentium 100 and got this huge message about 4 errors being found.
> > > > > > > > > These tests have been done with snapshots rtems-ss-20010109 and
> > > > > > > > > rtems-ss-20010126.  Has anyone else tested paranoia.exe on a PC lately and found
> > > > > > > > > the same problem?
> > > > > > > > >
> > > > > > > > > Joel Sherrill wrote:
> > > > > > > > >
> > > > > > > > > > angelo wrote:
> > > > > > > > > > >
> > > > > > > > > > > I have successfully run  RTEMS apps on a Pentium using the pc386 build,
> > > > > > > > > > > however, when I attempt to run the apps (including the hello world ) on a
> > > > > > > > > > > 386 with no co-processor, The console just display an infinite Exception
> > > > > > > > > > > which I cannot read.
> > > > > > > > > >
> > > > > > > > > > Hmmm.. I would be surprised if the lack of an FPU is causing this.  But
> > > > > > > > > > stranger things have happened over the years.  What RTEMS version are
> > > > > > > > > > you trying?  It might also be worth it to put a "while 1" loop in the
> > > > > > > > > > exception handler temporarily so the message won't disappear.
> > > > > > > > > >
> > > > > > > > > > > I suspect that it may be that soft float is required,
> > > > > > > > > > > but I am not sure.  Is there a way of ensuring that I am not trying to use
> > > > > > > > > > > the co-processor and am in fact using the soft floating point libraries.
> > > > > > > > > >
> > > > > > > > > > The answer is simple and not so simple at the same time.  The standard
> > > > > > > > > > gcc sources do not have soft-float support turned on for the i386 targets.
> > > > > > > > > > The RTEMS gcc patches and RPMs post 4.5.0 do include support for this.
> > > > > > > > > >
> > > > > > > > > > If you look at the ts_386ex target in recent snapshots, its CPU_CFLAGS
> > > > > > > > > > should be the basis for adding a new pc386 variant (like pc[56]86 and
> > > > > > > > > > pck6).  Right now all pc386 variants assume an FPU.
> > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Angelo Fraietta
> > > > > > > > > > >
> > > > > > > > > > > PO Box 859
> > > > > > > > > > > Hamilton NSW 2303
> > > > > > > > > > >
> > > > > > > > > > > Home Page
> > > > > > > > > > >
> > > > > > > > > > > http://users.hunterlink.net.au/~maaaf/
> > > > > > > > > > >
> > > > > > > > > > > There are those who seek knowledge for the sake of knowledge - that is
> > > > > > > > > > > CURIOSITY
> > > > > > > > > > > There are those who seek knowledge to be known by others - that is VANITY
> > > > > > > > > > > There are those who seek knowledge in order to serve - that is LOVE
> > > > > > > > > > >     Bernard of Clairvaux (1090 - 1153)
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Joel Sherrill, Ph.D.             Director of Research & Development
> > > > > > > > > > joel at OARcorp.com                 On-Line Applications Research
> > > > > > > > > > Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> > > > > > > > > > Support Available                (256) 722-9985
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Angelo Fraietta
> > > > > > > > >
> > > > > > > > > PO Box 859
> > > > > > > > > Hamilton NSW 2303
> > > > > > > > >
> > > > > > > > > Home Page
> > > > > > > > >
> > > > > > > > > http://users.hunterlink.net.au/~maaaf/
> > > > > > > > >
> > > > > > > > > There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> > > > > > > > >
> > > > > > > > > There are those who seek knowledge to be known by others - that is VANITY
> > > > > > > > > There are those who seek knowledge in order to serve - that is LOVE
> > > > > > > > >     Bernard of Clairvaux (1090 - 1153)
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Erik Ivanenko
> > > > > > > > CCMS Supervisor
> > > > > > > > University of Toronto
> > > > > > > >
> > > > > > > > Ph:  416-978-1900
> > > > > > > > Fax: 416-978-6650
> > > > > > >
> > > > > > > --
> > > > > > > Angelo Fraietta
> > > > > > >
> > > > > > > PO Box 859
> > > > > > > Hamilton NSW 2303
> > > > > > >
> > > > > > > Home Page
> > > > > > >
> > > > > > > http://users.hunterlink.net.au/~maaaf/
> > > > > > >
> > > > > > > There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> > > > > > > There are those who seek knowledge to be known by others - that is VANITY
> > > > > > > There are those who seek knowledge in order to serve - that is LOVE
> > > > > > >     Bernard of Clairvaux (1090 - 1153)
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Erik Ivanenko
> > > > > > CCMS Supervisor
> > > > > > University of Toronto
> > > > > >
> > > > > > Ph:  416-978-1900
> > > > > > Fax: 416-978-6650
> > > > >
> > > > > --
> > > > > Angelo Fraietta
> > > > >
> > > > > PO Box 859
> > > > > Hamilton NSW 2303
> > > > >
> > > > > Home Page
> > > > >
> > > > > http://users.hunterlink.net.au/~maaaf/
> > > > >
> > > > > There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> > > > > There are those who seek knowledge to be known by others - that is VANITY
> > > > > There are those who seek knowledge in order to serve - that is LOVE
> > > > >     Bernard of Clairvaux (1090 - 1153)
> > > >
> > > > --
> > > >
> > > > Erik Ivanenko
> > > > CCMS Supervisor
> > > > University of Toronto
> > > >
> > > > Ph:  416-978-1900
> > > > Fax: 416-978-6650
> > >
> > > --
> > > Angelo Fraietta
> > >
> > > PO Box 859
> > > Hamilton NSW 2303
> > >
> > > Home Page
> > >
> > > http://users.hunterlink.net.au/~maaaf/
> > >
> > > There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> > > There are those who seek knowledge to be known by others - that is VANITY
> > > There are those who seek knowledge in order to serve - that is LOVE
> > >     Bernard of Clairvaux (1090 - 1153)
> >
> > --
> > Angelo Fraietta
> >
> > PO Box 859
> > Hamilton NSW 2303
> >
> > Home Page
> >
> > http://users.hunterlink.net.au/~maaaf/
> >
> > There are those who seek knowledge for the sake of knowledge - that is CURIOSITY
> > There are those who seek knowledge to be known by others - that is VANITY
> > There are those who seek knowledge in order to serve - that is LOVE
> >     Bernard of Clairvaux (1090 - 1153)
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>    Support Available             (256) 722-9985

--
Angelo Fraietta

PO Box 859
Hamilton NSW 2303

Home Page

http://users.hunterlink.net.au/~maaaf/

There are those who seek knowledge for the sake of knowledge - that is
CURIOSITY
There are those who seek knowledge to be known by others - that is
VANITY
There are those who seek knowledge in order to serve - that is LOVE
    Bernard of Clairvaux (1090 - 1153)



More information about the users mailing list