This is the mail archive of the
mailing list for the GCC project.
Re: powerpc & unaligned block moves with fp registers
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: powerpc & unaligned block moves with fp registers
- From: laire at t-online dot de (Ralph Schmidt)
- Date: Fri, 2 Nov 2001 11:48:05 +0100
- Cc: gcc at gcc dot gnu dot org
- References: <email@example.comA24iwx10229@greed.delorie.com><200111020459.XAA26996@makai.watson.ibm.com>
On Thu, 01 Nov 2001 23:59:12 -0500
David Edelsohn <firstname.lastname@example.org> wrote:
> >>>>> DJ Delorie writes:
> DJ> Um, the 603e in big-endian mode can do unaligned integer moves all by
> DJ> itself, but traps sufficiently unaligned fp moves, according to the
> DJ> programming manual from Motorola. I'm not sure why you'd think that
> DJ> it's the operating system's fault that it's doing this, especially in
> DJ> an embedded system with no operating system.
> Because this is a performance issue. SLOW_UNALIGNED_ACCESS
> already discourages "sufficiently unaligned fp moves". Only the
> customer's OS requires stricter alignment just for FPRs. The current
> definition of SLOW_UNALIGNED_ACCESS is good for everyone else.
We also experience this FPU alignment problem. We're running a mixed mode
68k(emulation) and PPC OS and the original OS includes are based on 68k
Sometimes..mostly in struct copies..gcc generates fpu copies though the
alignment of the structures isn't really determined and that requires
alignment exception handling.
If we would use strict-aligment it would generate the most ugliest integer
code i've ever seen to handle these non ppc aligned OS structures so that's
not an option at all.
Personally i would like an option which just disallows the fpu to be used in not
"safe" structure copies or just not at all in not float code or that it would
do normal code for different aligned structures. I see no real sense in doing
this alignment workaround for integer.