This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Register-relative data addressing, especially m68k.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]