On Wed, May 16, 2012 at 10:55:30AM +0100, Julius Baxter wrote: > 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. >
I'm with Jeremy on this one, I don't see the point adding a l.lw, one look in the arch manual will make it clear that l.lwz and l.lws is equivalent on 32-bit. The only thing that is confusing at the moment is that l.lws isn't supported in or1200, something that is easily fixed by the patch proposed by Jeppe. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
