Aurelien Jarno <aurel...@aurel32.net> writes: > On 2017-07-21 10:56, Alex Bennée wrote: >> >> Richard Henderson <r...@twiddle.net> writes: >> >> > On 07/20/2017 05:04 AM, Alex Bennée wrote: >> >> +static softfloat_flags softfloat_mapping_table[] = { >> >> + { float_flag_inexact , softfloat_flag_inexact }, >> >> + { float_flag_underflow, softfloat_flag_underflow }, >> >> + { float_flag_overflow , softfloat_flag_overflow }, >> >> + { float_flag_invalid , softfloat_flag_invalid }, >> >> +}; >> >> +/* FIXME: 2a has no infinite flag */ >> >> + >> >> +static uint8_t sync_softfloat_flags_from_2a(float_status *flags2a) >> >> +{ >> >> + uint8_t flags = flags2a->float_exception_flags; >> >> + int i; >> >> + if (flags) { >> >> + for (i = 0; i < ARRAY_SIZE(softfloat_mapping_table); i++) { >> >> + struct softfloat_flags *map = &softfloat_mapping_table[i]; >> >> + if (flags & map->float2a_flag) { >> >> + softfloat_raiseFlags(map->float3c_flag); >> >> + } >> >> + } >> >> + } else { >> >> + softfloat_exceptionFlags = 0; >> >> + } >> >> + >> >> + return softfloat_exceptionFlags; >> >> +} >> >> + >> > >> > For conversions like this IMO it's better to make the compiler do the >> > work. C.f. target/alpha/fpu_helper.c and CONVERT_BIT. >> >> Cool, I'll look at that. >> >> > BTW, I think these TLS variables that softfloat3a are using are going >> > to be a real problem. It's one thing to do it temporarily like you >> > are here, coordinating between 2a and 3c, but later, when the front >> > end is fully converted? That's just nonsense. >> >> Wouldn't the other option to be to drop float_status out of the guests >> CPUEnv and grab it from the TLS variable instead? Of course all guests >> would need to be MTTCG enabled for that to work. > > As said in another email, some architectures actually use more than one > float_status. We therefore need to implement a solution like the one > proposed by Richard.
Ahh you mean more than one float_status for a given vCPU context? -- Alex Bennée