[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openrisc] Re: PC as GPR?



> > > I don't quite get your answer.  To clarify, I mean shared libraries
like
> > > Linux has (and full Linux is a target for OR), they can be mapped at
any
> > > address but they can not be relocated.  Therefore the code has to be
> > > position independent.
> > I am not pretty fammiliar with PIC. But I thought gcc and other utils
create
> > global table where they read jump addresses from. So, would this be ok:
>
> Ah, I see the misunderstanding now.  You are talking about using the
> offset tables.  I meant getting a pointer to them in the first place.

> 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.
I think others have similar solution. Does this make sense then:

l.lwz    r3,symbol_index(r22)
l.add    r3,r10,r3
l.jr    r3
l.nop

What kind of instructions did you have in mind?

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

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

When I'll have a bit of extra time I will check this on gcc, if they
have/planning
to do such utilities.

Marko


--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml