On Mon, Apr 23, 2012 at 8:55 AM, Jeremy Bennett <[email protected]> wrote: > 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.
OK, this and others are a good argument for l.trap being class I. I'll move it there. > >> > 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. And we think it's going to be used or useful enough to warrant inclusion in the multilib combinations? If I were doing the multilib stuff for the tool chain I wouldn't bother with it. Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
