On Wed, May 16, 2012 at 10:38 AM, Jeremy Bennett <[email protected]> wrote: > On Wed, 2012-05-16 at 10:25 +0100, Julius Baxter wrote: >> On Tue, May 15, 2012 at 2:23 PM, Jeremy Bennett >> <[email protected]> wrote: > > <snip> > >> > 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 was recommending this on the principle of forcing the user to be > explicit about what they intend. > > For consistency if we go down this route, you should also add l.lb and > l.lh as synonyms for l.lbz and l.lhz.
I think the point was that we shouldn't be encoding superfluous information in the mnemonic. Unless we have 16- or 8-bit versions of OR1K then we won't need to do this for l.lh and l.lb. Actually, my argument doesn't hold in the case of 64-bit, but given that we can only have 32-bit or 64-bit implementations of this architecture, I don't see anything wrong with adding a mnemonic which simplifies things in the 32-bit case. > > Do we know if other architectures default to zero or sign-extension in > their mnemonics? What does MIPS do? http://www.weblearn.hs-bremen.de/risse/RST/docs/MIPS/mips-isa.pdf Page A-94. It looks like they default to sign extended on 64-bit processors. They have a separate load word unsigned (LWU) which would be equivalent to our l.lwz. > >> I've added the proposal to the architecture spec page: >> >> http://opencores.org/or1k/Architecture_Specification#l.lw_assembly_mnemonic >> > > There wasn't a discussion page, so I've added a commentary on the > section itself. If you prefer, please move this to the discussion page. Yeah, no discussion page there. I would prefer discussion remain on the mailing list - those wiki discussion pages are cumbersome to edit and aren't easily organised by thread. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
