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