[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[openrisc] Re: PC as GPR?
On Tue, Mar 05, 2002 at 09:32:19AM +0100, Marko Mlinar wrote:
> Hi Andreas!
>
> > > l.addi r7,r7,0x1234
> > > l.jr r7
> >
> > 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.
> > Oh, I have missed that, that's good. So there is a usable format for
> > instructions already. Converting the rest of the doc to LaTeX sounds
> > like the way to go then. That should be some work, but not difficult
> > (just copy text from Word file and add markup and tables again in TeX).
> > It's just been some time since I did something in TeX last time...
> :) great. This will help us a lot. The documentation cycle is annoyingly
> long;
> If you have some extra time it would be nice if you can read it through also
> ;)
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.
> > Yes, that is possible. The missing multi register store/load still
> > requires to save each register individually. Subroutine calls are a quite
> > common thing in the average code so this will create more pressure on
> > memory bandwidth and instruction cache.
> >
> > Either a multi reg store would be appropriate or alternatively the
> > register window approach used by some other RISC architectures.
> True. But maybe it is a bit too late to change the architecture so
> drastically - the SW would need major changes.
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.
--
Andreas Bombe <bombe@informatik.tu-muenchen.de> DSA key 0x04880A44
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml