Re: gcc-2.95.2 problem with target powerpc-eabi

[Michael Meissner <meissner at cygnus dot com>]

On Fri, Oct 27, 2000 at 03:43:28PM +0200, Volker Barthelmann wrote:
> Hi,
> 
> > The compiler seems to optimize the copy by using load (lfd)
> > and store (stfd) double float instructions.
> >
> > Now my question. How can I avoid this, without using the
> > compiler option -msoft-float ? 
> > I think it should be possible if I make some adjustmenst
> > in the rs6000.md /.c /.h files and then rebuild the compiler.
> >
> > Has anybody any experience in doing this ?
> 
> The option -mstrict-align seems to prevent this behaviour.

I wouldn't expect the -mstrict-align option to do this, since both long long
and doubles have 64 bit alignment.  Current versions of the compiler seem to
generate the load/store floating point with -mstrict-align.

> Unfortunately, the manual does not document this (in fact, the
> documentation for this option does not seem to make much sense
> to me). I'm not sure whether this is the intended meaning of
> -mstrict-align or, if not, what it is supposed to do. However,
> the switch has been used for some time in several real-time
> operating-systems for this purpose.

When the Power computers where first designed, they were big endian only, and
allowed load of gprs to be on any alignment just like the x86, instead of the
more normal strict (or RISC) alignment rules that state a 16-bit load must be
aligned on a 2 byte boundary, a 32-bit load must be aligned on a 4 byte
boundary, and a single 64-bit load must be aligned on an 8 byte boundary.
Floating point registers aren't as generous, where the hardware allows loading
a 64-bit item that is aligned on a 4 byte boundary but not an 8 byte boundary.
When the PowerPC was first designed, the main PowerPCs (601, 603, 604) allowed
any alignment for the gprs and word alignment for the fprs only in big endian
mode.  On those chips in little endian mode, you had to use strict alignment.
There was a big effort to port Windows NT to the PowerPC, which of course is
little endian, and lots/some programs ran much slower than expected due to
trapping the little endian non-strict alignment references, fixing them up to
behave as if the load/store succeeded, and restarting at the next instruction.
So when the PowerPC 750 was being designed, they added support for little
endian mode to use the same alignment rules as big endian, except in using the
deprecated string and multiple word instructions.

Note, even though the hardware allows unaligned access, it is slower when the
machine has to fix things up, but it is on the order of a few cycles, and not
the hundreds or thousands of cycles trapping to the OS entails.

The -mno-strict-align option tells the compiler to assume it can use unaligned
loads and stores, and is default for big endian and off for little endian in
situations where it wants to do a multibyte load, but isn't sure the pointer is
aligned correctly.

Some of the embedded chips (most notably the IBM 40x chips, I don't recall for
the Motorola 8xx chips) do not support anything but strict alignment even in
big endian mode, which is why real-time OSes typically use -mstrict-align.  I
would expect most of them to use -msoft-float as well, since many of the
embedded chips also don't have floating point.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482