[openrisc] Re: PC as GPR?

[Andreas Bombe <bombe@informatik.tu-muenchen.de>]

On Thu, Mar 07, 2002 at 08:54:28AM +0100, Marko Mlinar wrote:
> > Since each shared object has its own offset table it can't be at an
> > absolute address.  So at every entry of an exported function it has to
> > calculate the pointer to the table, for which it definitely needs the PC
> > since only the relative offset to the code is fixed.
> Yes right, simple l.lwz won't be enough, you need extra l.add.
> 
> Well it can be defined in register model, that e.g. r10 holds the absolute
> address, which should be added to all the global tables in shared libraries.

Not sure what you mean, maybe you misunderstand shared library
requirements.  You could look it up in the ELF specification if you're
interested (I'm not 100% trustable on all the details, but I think I've
got a pretty good picture of it).

But in short:  There is nothing absolute in the executable
image of shared libraries.  The global offset table with the absolute
addresses is created by the shared object linker (/lib/ld.so under
Linux) and is to the code known only by its relative offset to the
code.  So at entry of an exported function the library code calculates
the GOT address by adding an offset to the PC and keeps that in a
register for future access (yes, e.g. r10).

Global data is then accessed through the table addresses (a few of the
slots are reserved for special further tables, e.g. the function call
table).

Every shared library has its own GOT and associated further tables since
it can be mapped at very different addresses in different processes and
also can not use a 'global' (per executable) table because a library
isn't in any way tied to an executable.

> What kind of instructions did you have in mind?

Now nothing special anymore.  It's just that the PC needs to be
accessible one way or the other.  Since the jmp and link doesn't go to
stack like the x86 equivalent it doesn't sound too horrible.  And the
l.mfspr for PC access is there, too.  Load from register+offset is all
we need to access GOTs after we got their pointers.

> > Umm, well, it has really been a _long_ time since my last TeX
> > experience.  I would have to get started again.  If noone stands up I
> > might do it, then.  No promises to whenever I'll get to it, however.
> I thought you volounteered. :)
> I was never an expert in TeX, but if you have some questions I will try to
> answer. There are also some TeX editors with GUI.

I sort of volunteer.  I can't work at it right now.  I wouldn't use TeX
GUI editors :) I'd just need some hours to get back up to speed.  I just
mean that if there is an active TeX user with some spare time I wouldn't
fight over the work.

> > Yeah, the register window functionality would need major changes.  A
> > store/load of multiple registers however is (at least from the software
> > point of view) a simple addition which doesn't change the architecture
> > in a significant way.  Except for making it much more icache efficient.
> 
> I was thinking that for embedded applications one could use post-linking
> optimization. At this stage you could remove most of the penalties caused
> by the software conventions, so register window would be practically
> extra work and power consumption.

I don't know what post-linking optimization you are referring to, but if
they modify code after loading, you should forget about using them with
Linux.

-- 
Andreas Bombe <bombe@informatik.tu-muenchen.de>    DSA key 0x04880A44
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml