On Sat, 2012-04-21 at 17:28 +0100, Julius Baxter 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
Hi Julius, It's a logical structure, except l.trap must be in class I for GDB. 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. 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). You might further reduce the MULTILIB variants by insisting that FPU requires class II/III to be implemented as well. Joern Rennecke is the deep expert on this. But I know that it can turn tool chain build times into hours rather than minutes. 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
