On Sun, Apr 22, 2012 at 7:57 AM, Jonas Bonn <[email protected]> wrote: > > On Sat, 2012-04-21 at 21:42 +0100, Jeremy Bennett wrote: >> On Sat, 2012-04-21 at 17:28 +0100, Julius Baxter wrote: >> > Class I should remain mandatory to implement. >> > >> > A new classification is proposed: >> > * Class II - Optional Maths: l.div*, l.mul* >> > * Class III - Optional Bit Manipulation: l.ext[bwh]*, l.ff1, l.fl1, >> > l.ror, l.rori >> > * Class IV - MAC Instructions - l.mac*, l.msb >> > * Class V - Remaining Optional Instructions: l.cmov, l.csync, l.msync, >> > l.psync, l.cust1-8, l.trap >> >> Hi Julius, >> >> It's a logical structure, except l.trap must be in class I for GDB. > > I tend to agree. Does this have a high cost (in terms of complexity or > otherwise) that mandates class V?
I laid out my thinking on this in this in my previous response to Jeremy, but essentially I see this instruction used only really for software debugging and by the kernel for userspace debugging. For an implementation without a debug unit (clearly going for maximum area saving) this instruction can probably be scrapped too. It's also not emitted by the compiler and shouldn't be used in any bare-metal libraries. > >> >> 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. > > It's not that bad. Class III isn't something the compiler will be > emitting, nor class V. > > I would say class IV should imply class II; i.e. you can't have class IV > without class II. > > So that leaves 3 multilib variants: class I only, class I+II, and class > I+II+IV. I don't think you want the MAC instructions emitted by the compiler. I'm not sure it's worth going to all the effort to have MAC instructions in our multilib variants or software libraries. > > With that argument, I'd be inclined to call them 'levels' instead of > 'classes'. Your processor can be level 1, 2, or 3; and classes III and > V go to other ORBIS sections (effectively), that may or may not be > implemented -- but the compiler and libraries shouldn't care. > > Matthew asked in other mail, but I'll respond here: Linux will run with > only class I but can make use of class III if present. Class II is > handled purely by the compiler, so Linux will use those only if the > compiler generates them. Class V is trickier: we don't need them today > as there is no implementation of weakly-ordered memory; but we _should_ > be using them because things will break when OpenRISC goes superscalar! > That said, they'll be hand-coded, not generated by the compiler. My thinking with class V instructions is that essentially any software which relies on them will, in future, be able to check via a presence bit for support of all instructions it is expecting. It will then be clear if anything it needs is missing and can find out ahead of time. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
