On Sun, 2012-04-22 at 11:22 +0100, Julius Baxter wrote: > On Sat, Apr 21, 2012 at 9:42 PM, Jeremy Bennett > <[email protected]> wrote:
<snip> > > It's a logical structure, except l.trap must be in class I for GDB. > > I guess so, but what of a tiny OR1K implementation without debug unit > (so no ability to software debug, one of the major uses of the trap > instruction) and without operating system making use of l.trap? I'd > like to say this is a valid configuration. GCC won't emit this guy, > too. Well you can still run a software debugger without a debug unit. You just have to write a l.trap exception handler that can communicate with the debug client. That's how gdbserver works for example. If it is really so tiny, then you won't be using C to program it. I haven't actually seen a 32-bit processor in this class - if size is that important, then you use 8-bit. C that cannot be debugged is not a usable solution. So you need an instruction that is guaranteed to cause an exception. I see little reason to replace l.trap which has served that purpose well. > If we could tie instructions to their units (like l.mac instructions > to the MAC unit, floating point to FPU etc.) I'd say l.trap is likely > to be needed really only when you have a debug unit. Perhaps this is > wrong in the case of an OR1K CPU running Linux (which I believe uses > l.trap instructions for userspace debugging?) but you're more than > likely to have a debug unit in that implementation anyway. > > It's a very marginal gain in terms of implementation size, so maybe > it's not worth it, but I still thing it should be an optional > instruction, basically depending on if you have the debug unit > implemented, and so should be class V. If it is a marginal gain, then l.trap must stay. Actually it should stay even if it isn't marginal. > > But it is a MULTILIB nightmare. Not something we have ever really sorted > > out properly for OpenRISC, but we will have to. With 5 classes, as a > > baseline there will be 5 versions of each plain library and 5 versions > > of each debug library. There is no point having a separate class if you > > can't compile for it. > > > > Then you'll want the versions with and without the FPU. Now you have 20 > > versions of the libraries. > > Class IV and all of class V are not likely to be present in the > standard libraries we'd want to multilib, right? None of those are > emitted by GCC and I think it's not too much for us to say they cannot > be used in any hand-coded parts of GCC? Leaving us with just 3 classes > to support - I, II and III and we can cope with that I would think. Class V won't be in the compiled code, but I certainly hope the compiler would be able to take advantage of MAC instructions. That's why you have those vectorizing passes in modern compilers! > > > > And then there are the profiling versions... > > > > GCC 4.7 does introduce some more fine-grained control of MULTILIB, but > > you are still going to have to decide which ones you want. > > > > I can think of some simplifications. Class V doesn't affect the compiler > > - at most you're going to do these through built-ins or hand-coded > > assembler. I suspect class III is a tiny bit of logic compare to mul and > > div, so I suggest merging class II and III. That then gets you down to 3 > > classes that affect the compiler (if you have MAC instructions, you want > > the compiler to use them). > > Serial multipliers and dividers are not so huge, and those rotate > instructions can have large logic overheads - each potentially infers > most of a barrel shifter. I do see what you're saying though - and > it's an extension of why I've lumped integer multiply and divide > support together - if you're going to have one, you're clearly not on > a major area budget and it's not likely to push you over the edge if > you have the other - and I agree that to an extent the same goes for > class III with class II. Maybe we should do this... > > I don't think we want to make the MAC instructions emitted by the > compiler, do we? That appears to be something for hand-coded DSP > algorithms alone. As note above you most certainly do want the compiler to emit MAC instructions. HTH, 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
