On Tue, Apr 24, 2012 at 12:55 AM, Jeremy Bennett < [email protected]> wrote:
> 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 > > You don't have to have configured RTL to build a tool chain. If you don't then you build to a default config which would duplicate what we are currently doing today. If you provide an RTL configuration then the config data can be extracted from it so that your build will use every feature available in the hardware. You also provide the ability to reduce features as needed. For example you can specify to not use hardware multiply and it won't even if the RTL supports it. You cannot force it to always use hardware multiply unless you have a RTL config file. It is quite workable. John Eaton
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
