Re: About hardfloat in ppc

[BALATON Zoltan]

On Fri, 1 May 2020, 罗勇刚(Yonggang Luo) wrote:
> That's what I suggested,
> We preserve a  float computing cache
> typedef struct FpRecord {
>  uint8_t op;
>  float32 A;
>  float32 B;
> }  FpRecord;
> FpRecord fp_cache[1024];
> int fp_cache_length;
> uint32_t fp_exceptions;
>
> 1. For each new fp operation we push it to the  fp_cache,
> 2. Once we read the fp_exceptions , then we re-compute
> the fp_exceptions by re-running the fp FpRecord sequence.
> and clear  fp_cache_length.

Why do you need to store more than the last fp op? The cumulative bits can 
be tracked like it's done for other targets by not clearing fp_status then 
you can read it from there. Only the non-sticky FI bit needs to be 
computed but that's only determined by the last op so it's enough to 
remember that and run that with softfloat (or even hardfloat after 
clearing status but softfloat may be faster for this) to get the bits for 
last op when status is read.

> 3. If we clear the fp_exceptions , then we set fp_cache_length to 0 and
> clear  fp_exceptions.
> 4. If the  fp_cache are full, then we re-compute
> the fp_exceptions by re-running the fp FpRecord sequence.

All this cache management and more than one element seems unnecessary to 
me although I may be missing something.

> Now the keypoint is how to tracking the read and write of FPSCR register,
> The current code are
>    cpu_fpscr = tcg_global_mem_new(cpu_env,
>                                   offsetof(CPUPPCState, fpscr), "fpscr");

Maybe you could search where the value is read which should be the places 
where we need to handle it but changes may be needed to make a clear API 
for this between target/ppc, TCG and softfloat which likely does not 
exist yet.

Regards,
BALATON Zoltan