qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] mips: Respect CP0.Status.CU1 for microMIPS FP b


From: Leon Alrae
Subject: Re: [Qemu-devel] [PATCH] mips: Respect CP0.Status.CU1 for microMIPS FP branches
Date: Fri, 7 Nov 2014 10:39:04 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 05/11/2014 20:16, Maciej W. Rozycki wrote:
>  Now as to CP0.Status.CU1, while fixing the 5Kc and 5KEc processors is an 
> obvious change, I think the removal of the extra check may not be such.  
> The thing is in the original architecture -- and it still stands for CP2 
> -- these bits used to control external coprocessors that may or may not 
> have been present.  For example to have an R3000 processor with an FPU you 
> wired an external R3010 unit to it.  Consequently all the CP0.Status.CUx 
> bits were always writable and the relevant logic to intereact with the 
> external chip enabled when requested.
> 
>  And there is software that relies on this property as prior to the 
> introduction of the modern MIPS architecture there was no CP0.Config1 
> register present to check the presence of an FPU with.  Instead what 
> software was supposed to do was to enable CP1, execute a CFC instruction 
> to read CP1.FIR that was supposed not to trap under these circumstances, 
> and check the value obtained in the Imp field (as it was then called) aka 
> ProcessorID.  If that was non-zero, an FPU was present, if it was zero 
> (due to the floating bus being strapped IIUC), no FPU was available. [2] 
> For example we have code in Linux doing this when run on the relevant 
> hardware.
> 
>  Obviously COP1X instructions would trap on CP0.Status.CU3 instead and for 
> example the FP emulator that we have in Linux is prepared for this 
> situation (whether it should really emulate a full MIPS IV if not higher 
> FP instruction set on a lower-ISA processor is another question).
> 
>  And I think all this draws the "right" implementation that we can make, 
> across all the three coprocessors actually, e.g. for CP1, except stores 
> and transfers from:
> 
>     check_cp1_enabled(ctx);
>     if (ctx->CP0_Config1 & (1 << CP0C1_FP)) {
>         handle_the_op();
>     }
> 
> for stores and transfers from:
> 
>     check_cp1_enabled(ctx);
>     if (ctx->CP0_Config1 & (1 << CP0C1_FP)) {
>         write_destination(read(source));
>     } else {
>         write_destination(0);
>     }

Yes, if we take into account also legacy CPUs, then this sounds like a
good way to go (instead of just removing extra check).

Thanks,
Leon




reply via email to

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