On Mon, 2012-04-23 at 20:09 +0100, R. Diez wrote: > > The number of design variants in hardware and software is mind boggling. > > We do need a linkage between our hardware configuration management > > and software creation so that when the architects choose a or1200 with > > mac then this information is passed into the sw tool chain so that > > mac instructions can be generated. This has to be automatic. > > That's something I can take on. The orbuild framework I've written can > already read file or1200_defines.v and modify only the parameters you > are intested about. At the moment, that feature is being used to > generate different CPU configurations for linting purposes, but it > could easily be invoked once more at the beginning in order to enable > the desired CPU instruction classes. The framework would then build a > matching toolchain.
Hi Ruben, That's an alternative approach. Just build a tool chain for the features your hardware implements. You would still need the debugging and profiling multilib variants, since these are not architectural options. The question is whether users would be happy losing control over those compiler options. If you have an FPU you would get hardware floating point instructions - you wouldn't be able to turn it off. Options like -msoft-mul/-mhard-mul would not be available. Potentially you could remove parts of the library code (for example the software FP routines). It does require that you have configured RTL available in order to build the tool chain. You'll need a mechanism to allow users to build a tool chain for Or1ksim, so you'll need to be able to read Or1ksim configurations as well. It might be best to avoid such monolithic dependencies - look at the hassle having GDB depend on Or1ksim has caused. Just let orbuild take options to specify the features or instruction classes the tool chain should support. 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
