Re: Register-relative data addressing, especially m68k.

[Ray Whitmer <ray at xmission dot com>]

On Wed, 25 Feb 2004, Jim Wilson wrote:

> So you want some kind of embedded pic/pid.  Most gcc support for pic was
> developed to support shared libraries for various operating systems.

That is clearly not a goal in this case -- especially not sharing common
data between shared libraries / applications, which although there
may be people doing it to significant advantage, I have always considered
a violation of proper encapsulation and I would always use methods to share
access to global data.

> Support for pic/pid for embedded systems is less common.  This is partly
> because there is less embedded work done.  But it is also partly because
> there is no common standard for embedded pic/pid support.  Different
> people want it done different ways, and there is no way to please
> everyone.  There is embedded pic/pid support in some targets though.

The SDS compiler, among others, supports this model.  So do a variety of
targets I have mentioned that apparently have never been directly supported
by gcc, such as palm, amigaos, etc.  I remember that is the way DEC
architecture for VMS worked under Alpha in some cases, etc.

It is understandable to me that you need a GOT if you are invoking methods
(or data) in seperate shared libraries.  It is not clear to me why you would
even use the GOT if the data is declared locally to a single executable, not
crossing executable boundaries, because the whole executable will be relinked
allowing offsets to be adjusted, not requiring any sort of activation-time
fixup of a GOT.

I am sure you may know of cases I do not.

But if a standard for this sort of GOT-less access was set as a reasonable
compromise, we could adapt to divergent details, as could others, I believe,
such as using %a4 as some do instead of %a5.

> You mention that you have no explicit initialization, but it isn't clear
> if it is safe to rely on that, as the compiler might need to generate
> some implicitly initialized data.

In this case, we are restricted to C and I cannot see where the initizalized
data would come from, but that is not an essential feature of the compilation
mode.

The important part is that the loader can determine where to get the
flashable read-only part of the program, and can also determine how big the
writable section must be to reserve it and point r5 to that section.  If there
is another method available that would perform any initialization (none in our
case), that does not seem like a big deal, as long as the loader is free to
initialize it only at the appropriate time and pass a5 as the location of the
data.

> Another issue here is that embedded pic/pid is not just a compiler
> issue.  You need compiler, assembler, linker, and loader support, and
> they all have to work together to achieve the desired goal.

Obviously I need loader support.  It is not so clear to me that I need
linker support or assembler support, but that could be true.

> You haven't clearly specified what kind of code you want.  You said you
> want A5 relative references to data, but there are lots of different
> ways to achieve that.  Specific examples of code that you want would be
> good.

With the current m68k back end in the 3.4 tree, if I compile with -msepdata
this results in the following:

Let's say I have the global variable foo.

A .comm declaration of foo appears.

Where the variable is referenced, the code is something like:

mov.l foo@got.w(%a5),%d0
mov.l %d0,%r

And then %r is used to access the data.

What we need instead is:

A contribution to a data section (with no GOT) at a named offset.

Where the variable is referenced, the code should be something like:

lea foo(%a5),%r

or

mov.l #foo,%d0
add.l %a5,%d0
mov.l %d0,%r

where the linker has set up foo as the offset of that variable from the
beginning of the total data section which is loaded into %a5 by the loader
/ activator.

> How can you implement pic/pid if you don't have a GOT?  Details please.
>   On the face of it, -msep-data does appear to do most of what you need.

a5 points to the data section that contains the variables, and the offsets
from a5 are to the actual data variables, not to an indirect reference to
the variable.

Perhaps what I need for now is an assembly post-processor that looks for the
GOT references and .comm declarations and changes them into something more
suitable for the Got-less pic model.  Perhaps that would be less susceptible
to breakage until the case can be appreciated for supporting this compilation
mode more directly in gcc.

When I do various Google searches, I find the same question WRT gcc in a
number of lists for people especially using m68k, sometimes experienced with
the SDS compiler or others which support this mode, etc. as well as the
palm and amigaos, both m68k architectures which rely on this sort of mode.

If it were just our own development effort, we would stick to SDS which
we have paid for and satisfies our needs, but the product is used by students
in classrooms all over the place, not unlike the way a palm is used with
applications that just stay active, but more suited for student use than palm.  Suitably-skilled Teachers and other third parties need to be able to write free
software for the devices and the price and other licensing restrictions on the
SDS compiler do not make that practical.

Thanks,

Ray