On Tue, May 15, 2012 at 2:23 PM, Jeremy Bennett <[email protected]> wrote: > 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.
I think it's fine. We can just specify that l.lw encodes as l.lwz and I think we achieve what we want. If the 64-bit tool chain needs a l.lws it can emit one, or the user can type one, but for all 32-bit cases and most 64-bit word-load cases, l.lw will be fine. I've added the proposal to the architecture spec page: http://opencores.org/or1k/Architecture_Specification#l.lw_assembly_mnemonic Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
