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
