On Tue, Jun 26, 2012 at 08:33:11AM +0100, Jeremy Bennett wrote: > On Tue, 2012-06-26 at 00:04 +0100, Rob Riglar wrote: > > > 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. >
I agree with Jeremy here, a proper binutils port would be of essence from the start, that will just make things easier in the long run. You're most probably right that creating the GCC port is the hard part, but there is a "shortcut" available. I'd be more inclined to use LLVM/Clang as a stepping stone, the effort required to get such a port up and running is a lot less steep (I'm clearly biased here though ;)) Without any prior compiler internals experience I think it took about a month, working a couple of hours each evening, to get the OR1K LLVM/Clang port compile u-boot and run it (admittedly, I had some initial help by the effort started by Jonas Bonn and the example OpenRISC LLVM backend by Anton Korobeynikov, but it's still a good reference how quick you can get something useful out of it). Around the 2 month mark I got uClibc and busybux compiling and running. A good point with starting compiler support early is that you will more easily be able to pinpoint what instructions/implementation details that makes sense and what not. > > 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. > I agree, and I like that you are inclined to move away from adding too much complexity. I believe that is one of the strengths with or1k, it is a very straight forward architecture (although perhaps not so exciting). My hopes for OR2K would be that it would keep this straightforwardness, and add some excitement in the mix ;) Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
