Comparing behavior of test-fesetenv.c on AMD Opterons and Intel Xeons: running FNSTENV on Opteron -- should it zero out __x87.__other?

NGie Cooper yaneurabeya at gmail.com
Wed Oct 14 18:51:37 UTC 2015


On Thu, Oct 8, 2015 at 2:33 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> On Thu, Oct 08, 2015 at 02:14:12AM -0700, Garrett Cooper wrote:
>>
>> > On Oct 8, 2015, at 01:06, Konstantin Belousov <kostikbel at gmail.com> wrote:
>> >
>> >> On Thu, Oct 08, 2015 at 12:38:15AM -0700, Garrett Cooper wrote:
>>
>> ...
>>
>> >> Hi kib!
>> >>
>> >> Ok -- that's what my gut was telling me when I was reading the spec, but I needed a second opinion. Interesting how Intel leaves the __other field alone and AMD [opterons] don't ;/..
>> >
>> > Your statement does not make any sense.  Re-read what I tell above.
>> > The __other field is not written by code, the code does not change
>> > by the matter of being run on Intel or AMD processors.  It just happens
>> > so that on one of your system the stack are seems to be zero, while on
>> > another, it does not.
>>
>> I thought __other corresponded to C0-C3 based on my read of the spec -- is that incorrect?
>
> What are C0-C3 you reference ? I can only think about condition code
> bits from the FPU status word which have that names, but the word is put
> into the __status field of fenv_t.

You're right. The __other field points to other registers in the FPU.
__status covers what both the AMD64 and Intel x64 specs refer to as
`C0-C3'.

> And, what spec did you read ?

I posted links to the specs in my original email. Unfortunately I
didn't fully rewrite the bug report so where they factored into it in
my original email was unfortunately lost:

1. http://support.amd.com/TechDocs/26569_APM_v5.pdf
2. http://www.intel.com/Assets/en_US/PDF/manual/253666.pdf

Thanks!
-NGie


More information about the freebsd-hackers mailing list