Re: [openrisc] Re: PC as GPR?

["Marko Mlinar" <markom@opencores.org>]

> 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

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

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

> It also makes moving memory operations a pain - strcmp, memset, ...
Yes, post increment would be very useful here.
Maybe block transfer instruction would be useful; e.g.:
l.sw (r1),r9,r10,r12,r14
But it would really be nice if it could be cache line aligned.

Marko


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