On Tue, 2012-05-15 at 13:43 +0100, Julius Baxter wrote: 
> On Tue, May 15, 2012 at 12:37 PM, R. Diez <[email protected]> wrote:
> > Hi OpenRISC gurus:
> >
> > I've seen in this mailing list a patch to implement instruction l.lws, 
> > which is missing from the Verilog core.
> >
> > It took me a while to realise that this instruction is in fact redundant in 
> > 32-bit processor implementations, as it does exactly the same as l.lwz, 
> > which is implemented in the current core.
> >
> > I have already pointed out a similar case with l.extws and l.extwz: they 
> > just copy a register to another one and are therefore redundant, you can 
> > use l.ori in order to achieve that.
> >
> > In the case of l.lws and l.lwz, I would drop l.lws from the specification 
> > and rename l.lwz to l.lw for 32-bit implementations, in order to reduce 
> > confusion and duplication. Few people would notice, as l.lws was never 
> > implemented in or1200 to begin with.
> >
> > The confusing part comes from the 's' and the 'z' suffixes, which suggest 
> > sign extension or zero extension, but in fact do nothing at all.
> >
> 
> The lwz and lws should do the same thing on 32-bit. We stuck to lwz in
> RTL and software for historical reasons. I think we should make the
> implementations work for both of these.
> 
> We could also add l.lw as an instruction mnemonic for 32-bit
> implementations which is assembled as l.lwz. Perhaps this is something
> we could capture in the architecture specification update (in the
> mnemonic examples for l.lwz and l.lws)

It is easy for the assembler to treat this as a synonym, but we should
make sure the slot remains in the instruction set space, to allow for
future 64-bit implementations.

I would discourage l.lw as a synonym. It does rather assume you are in a
32-bit world, and would be misleading for a 64-bit world.


Jeremy

-- 
Tel:      +44 (1590) 610184
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   [email protected]
Web:     www.embecosm.com

_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc

Reply via email to