[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[openrisc] Re: PC as GPR?
On Tue, Feb 26, 2002 at 08:55:33AM +0100, Marko Mlinar wrote:
> > Whether GPR or not, no PC relative addressing is a big loss. Think
> > loading of constant data (integer/float/double constants, strings),
> > which will have to be done in two ops.
> >
> > Think shared libraries. On x86, libraries have to use the ugly kludge
> > of "branch to following operation and pop address off the stack, add
> > offset and keep it around" on every library entry that can use global
> > data. It feels kinda dirty having to do that on a fresh, new ISA, too.
>
> you don't have to do this you can do something like:
>
> 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.
It can have global variables/constants and in order to refer to them, it
needs either PC relative addressing or knowledge of the current PC in
order to add an offset to obtain a global base pointer and carry that
around.
So there are two ways to get a GBP in r15, and this would have to be
done in the prologue of any public library function. One without direct
access to PC:
; save r15 along with other registers
l.jal 1f
l.nop
1: l.add r15,lr,#GLOBAL_BASE-.
One using the PC in SPR (assuming the moved PC points to the next
instruction, of which I am not sure):
; save r15 again
l.mfspr r15,r0,#SPR_PC
l.add r15,r15,#GLOBAL_BASE-.
> > > Yeah, it is old. It needs to be manually updated whenever Word file is
> > > updated. Idea is to replace Word with something that can automatically
> > > generate PDF (and HTML) on the server.
> >
> > That would most likely be a language defined with SGML (or rather that
> > newfangled XML, as more tools are likely available for it). Could also
> > be (La)TeX, but HTML is harder to generate from that.
> >
> > There is DocBook (defined in SGML and XML), but that's more targeted at
> > software manuals. Some templates would need to be defined for
> > instruction descriptions, which could also be used to extract e.g.
> > opcode tables from the manual.
> Currenlty the ISA is generated. It goes like this:
> gen_or1k_isa module (see or1k/gen_or1k_isa on CVS) generates LaTeX
> document,
> it is converted to PS and then to html; it is then added to the word
> document.
> Maybe it would be nice if anybody could take some time and do a LaTeX
> version
> out of MS word - so that gen_or1k_isa package would generate whole or1k
> document
> to ps and pdf ?
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...
> > Hm. To make the implementation simpler, I guess. Unless I miss
> > alternate facilities for this, stack operations will suck. There is
> > also no multi register store/load. Both of these are annoying for
> > function calls.
> This is not entirely true; look at prolog code cut:
> l.addi r1,r1,0xffffffd8
> l.sw 0x0(r1),r9
> l.sw 0x4(r1),r10
> l.sw 0x8(r1),r12
> l.sw 0xc(r1),r14
> l.sw 0x10(r1),r16
> l.sw 0x14(r1),r18
> l.sw 0x18(r1),r20
> l.sw 0x1c(r1),r22
> l.sw 0x20(r1),r24
> l.sw 0x24(r1),r26
> (using store with displacement, you need only one addi instead of many)
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.
--
Andreas Bombe <bombe@informatik.tu-muenchen.de> DSA key 0x04880A44
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml