Re: [Qemu-ppc] [Qemu-devel] [PATCH] fix fdiv instruction

[G 3]

On Jun 24, 2018, at 11:47 PM, Richard Henderson wrote:

> On 06/24/2018 11:38 AM, Programmingkid wrote:
> > void test_division_by_zero()
> > {
> >     Converter c;
> >     uint64_t expected_answer = 0x0;
> >     uint32_t actual_fpscr, expected_fpscr = 0xc4000010;
> >     reset_fpscr();
> >     set_fpscr_bit(ZE);
> >     asm volatile("fdiv %0, %1, %2" : "=f"(c.d) : "f"(1.0), "f"(0.0));
>
> Try
>
>     uint64_t expected_answer = 0xffff0000deadbeef;
>     ...
>     c.i = expected_answer;
>     asm volatile("fdiv %0, %1, %2" : "+f"(c.d) : "f"(1.0), "f"(0.0));
>
> to avoid depending on uninitialized data.  (This expected value is
> an SNaN with a deadbeef marker Just to be Sure.)
>
>
> r~


Ok I made this program and tried it on my iMac G5 (PowerPC 970).

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

// Used to convert unsigned integer <--> double
union Converter
{
    double d;
    uint64_t i;
};
typedef union Converter Converter;

int main (int argc, const char * argv[]) {
    Converter answer;
    answer.i = 0xffff0000deadbeef;
    //asm volatile("mtfsb1 27"); /* Set ZE bit */
    asm volatile("fdiv %0, %1, %2" : "=f"(answer.d) : "f"(1.0),  
"f"(0.0));
    printf("answer = 0x%" PRIx64 "\n", answer.i);
    return 0;
}

The result was the same.

When the FPSCR[ZE] bit is set, the answer is 0x0.

When the FPSCR[ZE] bit is not set, the answer is 0x7ff0000000000000.

This seems to be an undocumented feature.