tech-userlevel archive

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

Re: Default value of x87 registers' reserved bits



2010/5/28 Giles Lean <giles.lean%pobox.com@localhost>:
>
> Stathis Kamperis <ekamperi%gmail.com@localhost> wrote:
>
>> So all of the reserved bits seem to be set to 1. Is it fine to assume
>> that this is true in all cases ? Could someone please confirm it with
>> an AMD processor ?
>
> I think you should be _extremely_ cautious about relying on
> non-specified behaviour. Although I'm sure it's attractive
> from a performance standpoint, you have no guarantee that all
> future CPUs will remain consistent with current behaviour.
Yes, absolutely.

> Summary is (IMHO) that if the CPU architects have reserved the
> bits then there is at least some chance they'll use them some
> day even if they're not using them already, and I suspect that
> FP code in general and all the flavours and extensions of FP
> instructions on the x86 family of CPUs are considered esoteric
> enough by many people that identifying such a problem would be
> difficult.
Agreed, as well.

But the problem remains. We need to know their contents, so that when
we write into the 32bit registers, we don't involuntarily corrupt bits
31-16.

Solutions I see:

1) Assume that reserved bits are always 1. Document this assumption
into the code with some big fat warning, for the future programmer who
will be called to debug some awkward situation.
This situation will happen if for some reason CPU manufacturers change
the default value of some of the reserved bits from 1 to 0. Or if they
start using the reserved bits for internal purposes. (Both of these
scenarios _seem_ to not be true at the moment).

2) Like 1. but also add some diagnostics checks on the consumers of
FE_DFL_ENV, namely feupdateenv() and fesetenv(). Schematic code:

int
feupdateenv(const fenv_t *envp)
{
#ifdef    DIAGNOSTIC
            /* Save current fp environment to a temporary variable */
            ....
#endif
            /* Update the fp environment. If evnp is FE_DFL_ENV */
            /* we are worried */
            ....

#ifdef    DIAGNOSTIC
            /* Save new fp environment and assert that upper bits of */
            /* the status word register, control word register, etc */
            /* haven't changed in between */
            ....
#endif
}

3) Use some runtime singleton check to extract the value of the
reserved bits and setup the FE_DFL_ENV constant properly (actually the
object where FE_DFL_ENV points at, since it's a pointer to fenv_t). I
don't

What do you people think ?

Best regards,
Stathis


Home | Main Index | Thread Index | Old Index