RE: gcc-2.95.2 problem with target powerpc-eabi

["Volker Barthelmann" <volker dot barthelmann at 3SOFT dot de>]

Hi,

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

You're right. It does not help for long long. However, for standard
C (long long was an extension to C89) it helps, because non-float
types never have an alignment of 8 and therefore fp-copy is not
used as long as no floats or doubles are used.

At least that's what I hope.

[...]
> 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.

Ok, now I see. So the idea is that without strict-align the compiler
assumes that the chip supports unaligned accesses. From the text of
the manual ("assume that unaligned memory references will be
handled by the system") I thought that it refers to the operating
system supporting unaligned accesses through an exception-handler.

However, with this understanding of "system", the option made no
sense to me, because even if I my operating-system supported this,
I nevertheless wouldn't want unaligned accesses to be generated by
the compiler in this case.

I think strict-align should be turned on by default. 

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

There is still a serious problem. Consider, for example, an
MPC555 which has an FPU, 28KB RAM and is used in single-chip
systems. There it is not acceptable to waste the RAM needed
for unnecessary FPU-contexts. Therefore only some tasks will
be marked to use the FPU and FPU-contexts are only saved when
necessary.

This, however, implies that the programmer must know which
parts of his code might use the FPU. Usually it is possible to
tell a compiler not to use the FPU for anything but floating
point, i.e. the user knows that it won't be used unless he
uses floats/doubles. -msoft-float is not an option, because
the FPU might be needed in some tasks.

Volker