Re: [Qemu-devel] [PATCH] mips: Set the CP0.Config3.DSP and CP0.Config3.DSP2P bits

[Maciej W. Rozycki]

On Fri, 7 Nov 2014, Leon Alrae wrote:

> >> I was considering making mips32r5-generic less artificial and slowly
> >> evolve it towards some existing MIPS32R5 CPU, for example P5600 (which
> >> supports MSA, but doesn't support DSP ASE). Furthermore, none from the
> >> latest MIPS CPUs supports both ASEs.
> > 
> >  Why not leave mips32r5-generic alone then and add a correct entry for 
> > the P5600 instead?
> 
> Because it is additional configuration which is not specified anywhere
> that has to be maintain and tested. If a user wants to experiment with
> configurations, then it is relatively easy to add new or modify existing
> CPU definitions and this doesn't require any knowledge of QEMU. The only
> clear benefit for me from having a generic core is when new
> architectural feature is introduced and there is no actual CPU
> available. In this case we use generic core to expose new feature to a
> user. But in my opinion it eventually should be replaced by a real CPU
> containing supporting feature.

 I see having generic entries as a way to verify architecture 
conformance, including but not limited to make it possible to validate 
portability of software for which there is no suitable hardware 
available.  This is actually one of the main purposes for processor 
emulators to exist in the first place.  Here for example one could check 
if context switching is implemented correctly in the Linux kernel for a 
processor that implements both the MSA and the DSP register set -- which 
is something that is best done beforehand, before lots of people get in 
trouble once such hardware is decided to be made.

 And I disagree with a claim that such configurations are not specified 
anywhere -- they are, in the architecture specifications that allows 
them.  A good example in the context of the MIPS architecture is the 
semantics of the CP0.Status.MX bit in hardware that has both the DSP and 
the MDMX ASE implemented -- it has been specified very precisely in the 
architecture even though to the best of my knowledge no such hardware 
has actually ever been made.

 Whether the maintenance burden to have these extra configurations 
(pretty low IMO, but it's not my call to decide here) is justified or 
not is another question of course.

  Maciej