Soft Float for PC386

angelo angelo at hunterlink.net.au
Thu Feb 1 23:28:50 UTC 2001


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.

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?



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)

--
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