On Sat, Apr 21, 2012 at 11:28 AM, Julius Baxter <[email protected]> wrote: > On Tue, Aug 23, 2011 at 2:24 PM, Jeremy Bennett > <[email protected]> wrote: >> On Tue, 2011-08-23 at 14:01 +0100, Julius Baxter wrote: >>> Just to comment on some instructions. >>> >>> > For reference, the ORBIS32 class II instructions are: >>> > l.cmov >>> >>> Is this ever used by anyone? It's not emitted by the compiler as far >>> as I can tell. >>> >>> > l.csync >>> > l.cust1-8 >>> > l.div* >>> > l.ext[bhw]* >>> > l.ff1 >>> > l.fl1 >>> > l.mac*,l.msb >>> > l.mul* >>> > l.psync >>> > l.ror,l.rori >>> > l.sf*i (l.sfeqi,l.sfgesi etc.) >>> >>> These should probably not be class II. They are emitted by default >>> from the compiler I believe. >>> >>> > l.trap >> >> Absolutely. GDB won't work without it. >> > > Better late than never. > > A proposed updated scheme is outlined here: > > http://opencores.org/or1k/Architecture_Specification#Instruction_Classes > > Taken from the page: > > Proposed ORBIS Classifications > > 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 > > l.sf*i should be made class I. > > Classes II-IV will be all-or-nothing support classes, with class V > individually implementable. > > Some candidates for being moved from class I to class V are: > * l.sys (very operating system-specific) > > Presence bits > Presence bits in a new register should be added for classes II-IV, > with a bit for each instruction in class V. > > The idea behind this is a realistic multi-lib capability, and striking > a balance for a reasonably configurable system. > > I would say, if you're going to have hardware integer multiplication, > it's not much extra to have 30-40 odd registers and some adders for a > divider, too. The optional bit manipulation instructions, too, aren't > too hefty to add them all in once you need one. The MAC instructions > should be their own class, and will be implemented when the MAC unit > is enabled (indicated by the bit in the UPR). The remaining > instructions make sense to have their own individual presence bit, > which is basically what class V is. > > I mention moving l.sys to class V because you could potentially want a > very small implementation which didn't support this feature. I'm not > sure, though, if the saving is worth it. > > The add-with-carry instructions are still a bit confusing, too. It > would be nice if the whole carry feature was optional - it doesn't > look like anything uses it right now. > > Julius > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc
This seems well thought-out. I think the mac instructions would be better in their own instruction set, like floating point instructions as you would likely add a new module to support these instructions as opposed to adding the functionality to the existing integer core. For those of us rolling our own simulators, it would be nice to know which class(es) the toolchain compiles code down to. For instance, if I only support class I instructions I will be able to run all code produced with or32-elf and or32-linux (or whatever they are called nowadays). Or Linux requires Class I, II, and III support, ---Matthew Hicks _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
