Register-relative data addressing, especially m68k.

Register-relative data addressing, especially m68k.

[Ray Whitmer]

I have been asked to do a quick project for a company making whatever
modifications are necessary in GCC to get register-relative addressing
of the global variables to work, preferably using A5, but that could be
modified if necessary.  The applications thus compiled do not rely on
initialization (other than to zero) of such global variables.

I have seen this sort of scheme on a variety of processors and was suprised
that I couldn't find support for it already in GCC, although I understand
the desire to keep the compiler as simple as possible.

The common block scheme of indirection through a global table is not very
helpful (I have seldom found the common block scheme helpful and often
harmful, but I have no doubt it is useful to some).  Even turning on
-msep-data, although using A5, directs everything through the common block.

I had hoped that specifying -no-common-block on GCC would eliminate the use
of the GOT, but while it seems to allocate the storage without using the
.comm directive, it still is accessing indirectly through the GOT to get the
variables.  I need simple, direct access to global variables relative to a
base register such as A5.  This is not the first situation to require this
sort of scheme, and it is confusing to me why the code would continue to use
the GOT even when no common block is being created / accessed.

I have to deliver a solution fairly fast, which is unfortunate.  I would still
like to not detatch the effort too much from the main code base.

I have reviewed the palm and amigaos code variants which support this sort of
model, but it does not seem reasonable to use these variants, because
they have never been submitted back into the main code base and because they
contain lots of other modifications not relevant and even harmful to our
efforts, which would require us to have a significant derivitive of an
detached derivitive.

My questions are these:

1.  Have I overlooked some obvious way of getting this sort of base register
    offsetting from the current project code.

2.  If not, what is the best way to align the work so that it might get
    incorporated into the main tree.

    a.  Is there any work in progress towards supporting the -baserel sort of
        model in GCC, especially in m68k, but also on other platforms (I have
        seen this sort of model used on Alpha, etc.) -- even an outstanding
        enhancement request might be useful to review, as I have found plenty
        of requests for this sort of feature, but not in bugzilla.

    b.  Would developers be interested in reviewing my mods and considering
        them for 3.4.x?  Is there a patch of a similar scope that was well-
        executed that I should follow -- from enhancement request through
        justification, implementation, testing, and eventual release.

    c.  Am I right in considering the palm and amigaos enhancements bad
        examples because they have carried on in parallel for so many years
        with no incorporation into the base (if there had been, I might not be
        needing to do much at this point).

Unfortunately I don't have a lot of time right now, but I still want to do the
job as correctly as possible.

Apologies in advance for missing the obvious, as I have not contributed to gcc
before, so please set me strait.

Thanks,

Ray Whitmer
ray@xmission.com

Re: Register-relative data addressing, especially m68k.

[Jim Wilson]

Ray Whitmer wrote:
> I have been asked to do a quick project for a company making whatever
> modifications are necessary in GCC to get register-relative addressing
> of the global variables to work, preferably using A5, but that could be
> modified if necessary.  The applications thus compiled do not rely on
> initialization (other than to zero) of such global variables.

So you want some kind of embedded pic/pid.  Most gcc support for pic was 
developed to support shared libraries for various operating systems. 
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.

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.

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.

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.

> The common block scheme of indirection through a global table is not very
> helpful (I have seldom found the common block scheme helpful and often
> harmful, but I have no doubt it is useful to some).  Even turning on
> -msep-data, although using A5, directs everything through the common block.

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.

> I had hoped that specifying -no-common-block on GCC would eliminate the use
> of the GOT

-fno-common has nothing to do with whether or not you have a GOT.

> 1.  Have I overlooked some obvious way of getting this sort of base register
>     offsetting from the current project code.

It isn't clear why you can't use any of the existing options, such as 
-msep-data.

> 2.  If not, what is the best way to align the work so that it might get
>     incorporated into the main tree.

If you want to contribute code, you need to sign an FSF copyright 
assignment, and your employer will need to sign a copyright disclaimer.

The patches will have to be reviewed and approved.  This process can 
take a while sometimes.

>     a.  Is there any work in progress towards supporting the -baserel sort of
>         model in GCC, especially in m68k, but also on other platforms (I have
>         seen this sort of model used on Alpha, etc.) -- even an outstanding

A target independent implementation of this feature is probably not 
possible, because of interactions with the assembler/linker/loader.

>     b.  Would developers be interested in reviewing my mods and considering
>         them for 3.4.x?

I think it is too late to get something of this nature into gcc-3.4, as 
it is alread on a branch, and only bug fixes should be going on the 
branch.  Target dependent stuff which is unlikely to break anything can 
go on the branch, but these patches may not fall into that category.

>     c.  Am I right in considering the palm and amigaos enhancements bad
>         examples because they have carried on in parallel for so many years
>         with no incorporation into the base (if there had been, I might not be
>         needing to do much at this point).

Unclear.  I haven't looked at the palm/amigaos stuff, so I can't really 
comment on them.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Register-relative data addressing, especially m68k.

[Gunther Nikl]

On Wed, Feb 25, 2004 at 08:12:25AM -0700, Ray Whitmer wrote:
> I have been asked to do a quick project for a company making whatever
> modifications are necessary in GCC to get register-relative addressing
> of the global variables to work, preferably using A5, but that could be
> modified if necessary.

  Changing the compiler isn't enough. You also need modified binutils
  which support this relative addressing model.

> I need simple, direct access to global variables relative to a base
> register such as A5.

  With word-sized indexing your are limited to 64k of combined data+bss.
  With the 68020+ its possible to use longword indexing.

> I have reviewed the palm and amigaos code variants which support this sort
> of model, but it does not seem reasonable to use these variants, because
> they have never been submitted back into the main code base and because they
> contain lots of other modifications not relevant and even harmful to our
> efforts, which would require us to have a significant derivitive of an
> detached derivitive.

  It should be fairly easy to extract the required parts.

>     a.  Is there any work in progress towards supporting the -baserel sort of
>         model in GCC, especially in m68k, but also on other platforms (I have
>         seen this sort of model used on Alpha, etc.) -- even an outstanding
>         enhancement request might be useful to review, as I have found plenty
>         of requests for this sort of feature, but not in bugzilla.

  Well, I am planning to contribute it as part of the m68k-amigaos port.
  I don't know if its possible to make it a truly generic feature. There
  are problems with the baserel feature of m68k-amigaos which are either
  bugs in the port or generic bugs.

>     c.  Am I right in considering the palm and amigaos enhancements bad
>         examples because they have carried on in parallel for so many years
>         with no incorporation into the base (if there had been, I might not be
>         needing to do much at this point).

  Contributing to GCC isn't all that easy. It needs time and patience.
  There had been attempts to contribute m68k-amigaos but it never happened.

  Gunther

Re: Register-relative data addressing, especially m68k.

[Ray Whitmer]

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

Re: Register-relative data addressing, especially m68k.

[Ian Lance Taylor]

Ray Whitmer <ray@xmission.com> writes:

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

I did this once, many many years ago, in gcc 1.37.1:
    http://groups.google.com/groups?q=Ian+Lance+Taylor+AMOS+gcc+1.37.1&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=9012162035.AA00827%40uunet.uu.net&rnum=2

Actually the first significant work I did on gcc.  I doubt that the
patch is particularly useful now, but it's mildly amusing that the
functionality still isn't in there.  More amusing for me than for you,
I suppose.

If you can assume 68020 or higher, I think you can do what you want
using GO_IF_LEGITIMATE_ADDRESS and LEGITIMIZE_ADDRESS.  But I think
you will need additional relocations in the assembler and linker, for
``offset from data base address''.

Ian

Re: Register-relative data addressing, especially m68k.

[Jim Wilson]

On Thu, 2004-02-26 at 07:29, Ray Whitmer wrote:
> It is understandable to me that you need a GOT if you are invoking methods
> (or data) in seperate shared libraries.

That seems to make sense.  I can't think of an obvious reason why we
need a GOT if we will never have shared libraries.  We do still need
assembler/linker support to create/resolve special relocations though,
and not all targets will have the necessary relocations.

Some targets allow putting variables inside the GOT to eliminate one
indirection.  This can be done if the variables are "owned" by the
executable, i.e. that are defined in the executable, and can not be
overridden by another module.  If there will never be any shared
libraries, then all variables are "owned".  If all variables can be put
in the GOT, then the GOT essentially becomes the entire data section,
which is basically what you want.

It looks like we have at least 3 m68k examples now, the AMOS work from
Ian, and the Palm and AmigaOS work you already mentioned.

It should be possible to get something like this accepted into the FSF
gcc sources, but it is likely to take some time and effort to get
everything reviewed and accepted.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Register-relative data addressing, especially m68k.

[Gunther Nikl]

On Thu, Feb 26, 2004 at 11:23:14AM -0500, Ian Lance Taylor wrote:
> Ray Whitmer <ray@xmission.com> writes:
> 
> > 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.
> 
> I did this once, many many years ago, in gcc 1.37.1:
>     http://groups.google.com/groups?q=Ian+Lance+Taylor+AMOS+gcc+1.37.1&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=9012162035.AA00827%40uunet.uu.net&rnum=2
> 
> Actually the first significant work I did on gcc.  I doubt that the
> patch is particularly useful now, but it's mildly amusing that the
> functionality still isn't in there.  More amusing for me than for you,
> I suppose.

  Its not in the FSF sources, but it does exists. The m68k-amigaos port
  works with 3.3, 3.4 and mainline (ableit there are bugs which might be
  port bugs or generic GCC bugs).

> If you can assume 68020 or higher, I think you can do what you want
> using GO_IF_LEGITIMATE_ADDRESS and LEGITIMIZE_ADDRESS.

  m68k-amigaos overrides LEGITIMATE_PIC_OPERAND_P.

> But I think you will need additional relocations in the assembler
> and linker, for ``offset from data base address''.

  Thats correct.

  Gunther

Re: Register-relative data addressing, especially m68k.

[Gunther Nikl]

On Thu, Feb 26, 2004 at 07:13:38PM -0800, Jim Wilson wrote:
> It should be possible to get something like this [baserel support]
> accepted into the FSF gcc sources, but it is likely to take some
> time and effort to get everything reviewed and accepted.

  I intend to contribute m68k-amigaos which adds baserel support to m68k.
  However, I don't know what would be needed to make it a generic m68k
  addition. Currently its restricted to the target. And without binutils
  support its not very useful. The m68k-amigaos binutils modifications
  are not in mainline binutils.

  Gunther

Re: Register-relative data addressing, especially m68k.

[Ray Whitmer]

On Fri, 27 Feb 2004, Gunther Nikl wrote:

> On Thu, Feb 26, 2004 at 07:13:38PM -0800, Jim Wilson wrote:
> > It should be possible to get something like this [baserel support]
> > accepted into the FSF gcc sources, but it is likely to take some
> > time and effort to get everything reviewed and accepted.
>
>   I intend to contribute m68k-amigaos which adds baserel support to m68k.
>   However, I don't know what would be needed to make it a generic m68k
>   addition. Currently its restricted to the target. And without binutils
>   support its not very useful. The m68k-amigaos binutils modifications
>   are not in mainline binutils.

Does it make sense to contribute m68k-amigaos that does not run with
mainline binutils?  I always thought the two were supposed to work
together.  I am just asking a question, not trying to make an argument.

By the way, where do I find the modified binutils?  When I saw the modified
gcc for amigaos, I saw no references to modified binutils, but perhaps I
missed something.

Ray Whitmer
ray@xmission.com

Re: Register-relative data addressing, especially m68k.

[Gunther Nikl]

On Fri, Feb 27, 2004 at 07:58:17AM -0700, Ray Whitmer wrote:
> On Fri, 27 Feb 2004, Gunther Nikl wrote:
> >   I intend to contribute m68k-amigaos which adds baserel support to m68k.
> >   However, I don't know what would be needed to make it a generic m68k
> >   addition. Currently its restricted to the target. And without binutils
> >   support its not very useful. The m68k-amigaos binutils modifications
> >   are not in mainline binutils.
> 
> Does it make sense to contribute m68k-amigaos that does not run with
> mainline binutils?  I always thought the two were supposed to work
> together.  I am just asking a question, not trying to make an argument.

  I can't comment on that. The binutils modfications are freely available.

> By the way, where do I find the modified binutils?  When I saw the modified
> gcc for amigaos, I saw no references to modified binutils, but perhaps I
> missed something.

  The diffs can be found here:

    ftp://ftp.geekgadgets.org/pub/geekgadgets/amiga/m68k/snapshots/current/diffs/binutils-2.9.1-diffs.gz

  This diff can't be used with newer versions.

  There is a port to a newer version but I don't know how well it works.

    ftp://ftp.geekgadgets.org/pub/geekgadgets/amiga/m68k/alpha/binutils/binutils-2.13.1-gg-morphos-amithlon-2002-12-11.diff.bz2

  The alpha part in the pathname isn't something you need to worry about.

  Gunther