On Tue, 2012-06-26 at 00:04 +0100, Rob Riglar wrote: > Hi Julius & Jeremy, > > I attempted to join the mailing lists with a spamable new email > address [email protected]. > I think I was partially successful but the openrisc.net website timed > out when confirming.
Hi Rob, I've transferred this discussion to the mailing lists. I don't know what went wrong with signing up to openrisc.net, but Jonas Bonn (who owns that list) should pick up this message and add you manually. > > I'd like to get to a point where we have a fair bit of the > implementation work done before we lock down the ISA, so we can fully > evaluate the impact of the choices. For example, have a basic tool > chain and simulator which we can tweak with different instructions and > see the performance and code size impacts on a set of software, say > the GCC/newlib libraries, u-boot, and an RTOS or two. Anyway, that's > the sort of thing I'm working toward at the moment, but first is to > have a bit of a think about the different options available to us for > the basic instruction set. > > > I really like this idea Julius. If there was a rough and ready > toolchain & ISS, we'd be able to prototype & evaluate different ISA > options and see how they play out with some different use cases, and > how well suited they would be to being implemented in RTL. > Creating a GCC port is the hard part in this equation (for 16-bit > instruction support which probably can't build upon the OR1K port too > easily); though to this end, I guess as a first pass, a simple single > file noddy assembler could be knocked up in an afternoon. A simple assembler can be knocked up, but I suggest a CGEN assembler would be the better route. Still quick (although not an afternoon) and should give you the basis of both an assembler and simulator. You'll need a linker/loader as well. I think Julius Baxter has been working on updating the CGEN spec for OR1K and that should be a good starting point. > A couple of other points I've been thinking about on OR2k 16-bit > instructions (I haven't finished reading all the existing discussions > on this subject yet so please excuse me if some of these have been > covered one way or another); I suggest looking at the statistics Julius collected on instruction usage frequency. That helps to inform this discussion. > - An implementation should be able to be fully functional with just > 16-bit instructions, e.g. no crazy requirements like having to write > ISRs in 32-bit instructions, etc. > > - I don't think you can justify loosing 1-bit out of 16 to indicate > 16-bit mode on a per instruction basis. I can see why this logically > cleaner and probably a little easier to implement but you pay for it > by reducing code density. > (If selecting a different method, would need to be careful not to any > infringe patents). > > - The instructions themselves need to be able to map to a 32-bit > equivalent probably in quite a simple way, where 16-bit is the subset > and 32-bit is the superset. So for this to be true, every instruction > in the 16-bit ISA would have a direct equivalent in 32-bit mode. > This would faciliate the ability to use a simple frontend instruction > decoder to provide this 16-bit instruction mode. > > - I think you could ditch the 64-bit data manipulation instructions > from the 16-bit ISA. If you want to manipulate 64-bit data, you are > probably aiming at a different market from implementations that would > benefit from a 16-bit ISA. > > Having implemented an ARMv6M (thumb32) simulator a while back, I > personally think we should seek to avoid complex instructions like > 'Load/Store multiple registers' as implementing them complicates the > whole thing. > I'm sure the code density is improved by having them, but to me, the > tradeoff isn't worth it with the added complexity. > > I've run out of steam for tonight. I know I should send this kind of > stuff to the mailing list but I wanted to read up on the existing > discussions before doing so. All good points for discussion. 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
