[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] Floating point unit bugs
From: |
Aurelien Jarno |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] Floating point unit bugs |
Date: |
Tue, 9 May 2017 00:13:04 +0200 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
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