More MVME167 BSP

[Charles.Gauthier at iit.nrc.ca (Charles Gauthier)]

(Background  information: I had problems printing out of floating point numbers when
using the msoft-float variants of libc, libm and libgcc for a Motorola MVME167, which
uses a MC68040 processor. The MC68040 as a built-in FPU, but it does not implement the
full MC68881 math coprocessor instruction set. The missing instructions must be
implemented in software. The rational for using the msoft-float variants was to avoid
linking in the floating point support package, FPSP, that implements those missing
instructions, if it was not necessary to do so. My newlib-1.8.0 was built with gcc
2.8.1 and configured manually as per the instructions in the RTEMS supplement).

Yesterday, I rebuilt all the tools and rtems from scratch using the built scripts. I
can now report that newlib prints out the correct results for floating point numbers
even with the msoft-float variants of the libraries. The big change is that I switched
from gcc 2.8.1 to egcs-1.1b. Perhaps there is a bug in gcc 2.8.1 that caused it to
generate incorrect code in the msoft-float libraries. Another possibility is that your
build scripts set up the configuration properly whereas the manual procedure did
not(playing with limits.h?). In any case, I don't have the desire to track the problem
down. I am happy that all is well, or almost...

Re-reading my previous message (private email to Joel Sherrill), I can see that it was
not clear. Paranoia works just fine with the default variants of libc, libm and libgcc
(the 68020 variants). These variants can be used in this test because the FPSP is
installed to catch the unimplemented floating point instruction exceptions coming from
newlib floating point I/O functions. BUT, paranoia still does not work with the
msoft-float variants. I do not believe that there is a bug in paranoia. The symptom is
that paranoia goes into an infinite loop at milestone 40. The only difference in the
loop is the variant of floor() that gets linked in. I therefore suspect that there is
a problem (bug?) either in floor(), or in the floating point code in libgcc.a. Again,
it does not seem productive at this time to track this down.

I would recommend the following approach when building MVME167 applications:

- If the application does anything more sophisticated that simple floating-point
arithmetic and I/O, use the FPSP and link with the default variants of libc, libm and
libgcc. The MVME167 port is set up to install the FPSP by default, and to link with
the default variants of the libraries (for all samples and tests in the rtems
distribution).

- If the application does not do any floating-point operations or floating point I/O,
comment out the line that installs the FPSP in bsp_start(). Link against either the
default variants of the libraries or the msoft-float variants. It probably does not
matter which variants are used given that no floating-point operations are done.

- If the application does only simple floating point operations or does floating point
I/O, and if the overhead of the FPSP is not acceptable, remove it and link the
application with the msoft-float variants of the libraries.

The mvme167.cfg file could be set up to set the appropriate flags when building the
system. However, it might be preferable to select the link flags on a per application
basis. I will look at ways of doing this.

Charles

joel at OARcorp.com wrote:

> On Mon, 22 Feb 1999, Charles Gauthier wrote:
>
> > In a nutshell, here is what I discovered.
> >
> > The default variants of libc, libm and libgcc assume that a 68881 coprocessor is
> > present. Without the FPSP, any floating point operation, including printf() with
> > a "%f" format specifier, is likely to cause an unimplemented instruction
> > exception.
> >
> > The FPSP works with the default variants of libc, libm and libgcc. It does not
> > work in conjunction with the msoft-float variants. The paranoia test goes into
> > an infinite loop at milestone 40. I am guessing that floor() is returning an
> > incorrect value.
> >
> > The msoft-float variants of libc, libm and libgcc appear to do floating point
> > I/O properly. They only failed in paranoia. Offhand, I can't think of why they
> > would conflict with the FPSP, so I think that there is something wrong with the
> > msoft-float code. It might be my installation.
> >
> > Given my experiences, I decided to install the FPSP in bsp_start(), and
> > to link against the default variants of libc, libm and libgcc. This
> > causes the executables to increase in size by about 60 KB. The README
> > file and the mvme167.cfg specify how to remove the FPSP, and how to link
> > against the msoft-float variants of the libraries. This is not what Eric
> > Norum had done: on my host, his gen68360_040 port links RTEMS code with
> > the msoft-float variants of libc and libm, and the default variant of
> > libgcc. In this configuration, the output of printf() with "%f" is
> > garbage on my target.
> >
> > A patch of the modified files is included.
>
> I have applied the patch.
>
> All in all, this sounds like something to ask about on the rtems-list or
> crossgcc.  I do not have the expertise in the FP emulation code to know
> what it should work with.
>
> My understanding is that FPSP implements trap handlers for missing
> instructions and should make up the difference between a 68681 and the 040
> FPU. If it is not passing paranoia, then there is a but IMO.  But I would
> guarantee my understanding enough to tell you that is the case for sure.
> Ask the list.
>
> --joel