Re: [Qemu-devel] Floating point unit bugs

[Aurelien Jarno]

On 2017-05-07 17:48, G 3 wrote:
> I made a diagnostic program for the floating point unit. It will test
> various PowerPC floating point instructions for compatibility with the
> PowerPC G3 processor. It was tested on a PowerPC G3 and G5 system. The
> results of the program in qemu-system-ppc were pretty bad. About every
> instruction tested is not implemented correctly.
> 
> Here is the download link to the program: 
> http://www.mediafire.com/file/6j9tqubvk73lkw1/floating_point_test_program.zip

Some comments on the code.
> 
>     /* Check if everything is alright */
>     uint32_t fpscr;
>     asm volatile("mffs f0");
>     asm volatile("stfd f0, 40(r1)");
>     asm volatile("lwz %0, 44(r1)" : "=r"(fpscr));
>     if (fpscr != 0) {
>         printf("Warning: fpscr not equal to zero: 0x%x\n", fpscr);
>     }

This is overly complicated and just doesn't compile with recent GCC
versions. What about something like:

    Converter c;
    asm volatile("mffs %0" : "=f"(c.d));
    fpscr = (uint32_t)c.i;


> /*
>  * The action to take if a test fails
>  * Input one: message string
>  * Input two: actual fpscr value
>  * Input three: expected fpscr value
>  * Input four: actual answer
>  * Input five: expected answer
>  */
>  void test_failed(const char *message, uint32_t actual_fpscr, uint32_t
> expected_fpscr,
>                   uint64_t actual_answer, uint64_t expected_answer)
>  {
>     printf("%s\n", message);
>     printf("expected answer: 0x%" PRIx64 "\n", expected_answer);
>     printf("  actual answer: 0x%" PRIx64 "\n", actual_fpscr);

This is wrong. It should be actual_answer instead of actual_fpscr. That
is why all the instructions seems totally wrongly implemented. Note that
compiling with -Wall would give you a warning:

| main.c: In function ‘test_failed’:
| main.c:146:5: warning: format ‘%llx’ expects argument of type ‘long long 
unsigned int’, but argument 2 has type ‘uint32_t’ [-Wformat=]
|      printf("  actual answer: 0x%" PRIx64 "\n", actual_fpscr);
|      ^

So I think the cone needs to be improved a bit before we can conclude
anything.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
address@hidden                 http://www.aurel32.net