Re: [m68k] PIC fixes

["Aaron J. Grier" <aaron at frye dot com>]

On Tue, Dec 20, 2005 at 10:30:51PM +0000, Paul Brook wrote:
> > according to my reference manual, 68030 and 68040 can also do 32bit
> > displacements, so checking only TARGET_68020 is not sufficient.
> 
> TARGET_68020 is true for all 680x0 cores where x > 2.

handy!  I hadn't realized the TARGET_ flags were or-ed together with the
default flags.  and for 68020/030/040/060 family, that works.

I'm trying to get TARGET_CPU32 split out from TARGET_68020.  the ISAs
are not identical, (cas, cas2, specifically,) which was an issue last
time I tried to get libstdc++-v3 running.  I also ran into it with
RTEMS, since __mc68020__ was being defined when -mcpu32 was set, which
breaks the assumption that cpu32 is a 68020 minus bitfield instructions.

this all traces back to the thread started here:

http://www.rtems.com/ml/rtems-users/2004/november/msg00197.html

note that the patch presented there ended up being only a half-fix,
since TARGET_68020 wasn't being defined, so straight 68000 code was
being generated, which is really really inefficient.  hence my desire to
have a separate TARGET_CPU32, which the new .opt stuff in gcc4 seems to
make fairly painless.

it's maddening since the code generation isn't really the problem; just
the macros.  I've taken the (arguably heavy-handed) approach and have
been floating a patch which adds TARGET_CPU32 and basically turns
references for TARGET_68020 to TARGET_68020 || TARGET_CPU32.

ugh.

it's seems like there's got to be a cleaner way to express the not-
exactly-forward-compatible 68k family (including coldfire) to gcc.

> > if USE_GAS is enabled, could jbsr be generated, and let gas figure
> > out if the displacement will fit into a word or byte?
> 
> IIUC jbsr turns an out of range relative branch into an absolute jump.
> We're generating PIC code, so this isn't an option.

http://sourceware.org/binutils/docs-2.16/as/M68K_002dBranch.html

the absolute jumps are only used on 68k targets that don't have long
displacement, like 68000 and 68010, and as far as I know, PIC has never
worked for them with gcc.

-- 
  Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron@frye.com