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