Taking a stab at register-relative data addressing on m68k...

[Ray Whitmer <ray at xmission dot com>]

I believe I am closing in on the modifications I need to allow it to generate
code for m68k embedded devices.  While this is a ways away from any possible
proposed patch, I could use some advice implementing my simple modifications.

-msep-data seems very close to what I need.  I do not believe it is necessary
to modify binutils, and modifications to gcc should be a few lines as opposed
to tens of thousands of lines of modifications in the palm and amigaos efforts.
I have far fewer issues.

Any help on how to approach these small changes would be appreciated.  The
model is not making much sense to me yet, despite the documentation and code
that I have studied.

Here is what I have thus far:

1.  -msep-data only works in -fPIC mode, not in -fpic mode.  This is a problem
for me only because -fPIC does not work on the m68000 variety of machines.
Instead of trying to make -msep-data work with -fpic, I would prefer to make
-fPIC work with -m68000.  I have begun doing this by testing where the
target is not at least -m68020 or Coldfire, replacing

bsr.l foo

with:

move.l #foo-.-8,%%a1
jsr 0(%%pc,%%a1)

which should be a proper pcrel -fPIC sequence for m68000 processors.  This
was not difficult to find.

A similar approach should be followed for data references, but I have not
figured out exactly where the changes need to be made.

2.  The GOT is not useful or desirable for our simple platform which uses no
shared libraries.  Where current code moves the address of the global
symbol foo to %d0 as:

move.l foo@GOT.l(%a5),%d0

I would like to substitute:

move.l #foo, %d0
add.l %a5,%d0

For m68020 / Coldfire, there may be a simpler lea instruction that works.

This causes data access to occur relative to %a5 pointing at the start of
the data segment.  It is the responsibility of the linker script to zero-base
the writeable data sections for the loader to allocate and place in %a5.

But I have spent two days trying to figure out how to modify m68k.c and
m68k.md in a minimal way to accomplish this simple change.  It seems that
the move.l is coming from the function output_move_simode and foo@GOT is
generated by print_operand_address, but I have not figured out how to
detect the above situation and handle it, since the behavior seems
scattered all over the place.  Any hints?

I have not yet addressed making this behavior conditional on a switch or
whether it might be possible to develop a common strategy between embedded /
palm / amigaos.  Gunther, is there a sharable strategy here?

Thanks,

Ray Whitmer