qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leon Alrae
Subject: Re: [Qemu-devel] [PATCH] mips: Set the CP0.Config3.DSP and CP0.Config3.DSP2P bits
Date: Fri, 7 Nov 2014 20:06:02 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0

On 07/11/14 17:36, Maciej W. Rozycki wrote:
> On Fri, 7 Nov 2014, Leon Alrae wrote:
> 
>>>  I have been working with the current trunk, the change applies 
>>> correctly there AFAICT.
>>
>> 55a2201 commit added (1 << CP0C3_MSAP) to CP0_Config3 for
>> mips32r5-generic which is not present on your patch.
> 
>  Indeed, my mistake for some reason.
> 
>>>  I have no objections to changing mips32r5-generic, it is artificial 
>>> anyway.  But what do you mean by DSP and MSA on one CPU having no sense, 
>>> is there a conflict between the two ASEs?
>>
>> 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.

Regards,
Leon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]