On Sun, Jun 24, 2018 at 11:24:17PM -0400, G 3 wrote: > > On Jun 24, 2018, at 8:46 PM, David Gibson wrote: > > > On Fri, Jun 22, 2018 at 10:22:58PM -0400, John Arbuckle wrote: > > > When the fdiv instruction divides a finite number by zero, > > > the result actually depends on the FPSCR[ZE] bit. If this > > > bit is set, the return value is zero. If it is not set > > > the result should be either positive or negative infinity. > > > The sign of this result would depend on the sign of the > > > two inputs. What currently happens is only infinity is > > > returned even if the FPSCR[ZE] bit is set. This patch > > > fixes this problem by actually checking the FPSCR[ZE] bit > > > when deciding what the answer should be. > > > > > > fdiv is suppose to only set the FPSCR's FPRF bits during a > > > division by zero situation when the FPSCR[ZE] is not set. > > > What currently happens is these bits are always set. This > > > patch fixes this problem by checking the FPSCR[ZE] bit to > > > decide if the FPRF bits should be set. > > > > > > https://www.pdfdrive.net/powerpc-microprocessor-family-the-programming-environments-for-32-e3087633.html > > > This document has the information on the fdiv. Page 133 has the > > > information on what action is executed when a division by zero > > > situation takes place. > > > > I'm looking at that table and there is definitely no mention of a 0 > > *result* in any situation. So this patch is definitely wrong on that > > point. If there's something else this is fixing, then the commit > > message needs to describe that. > > I did not find any mention of a zero result *yet*. There could be mention of > something in another document. I will see what I can find. Right now I do > have example code that I ran on a PowerPC 970 CPU and the results are as > follows: > > When dividing by zero: > > if FPSCR[ZE] is enabled > then answer = 0
Really? Or is it just that the result register already contained zero and is being left unchanged as the document says should happen? > if FPSCR[ZE] is disabled > then answer = 0x7ff0000000000000 > > I think this feature may be undocumented. > > Here is the example program I used. When I ran this program, the FPSCR is > set to zero initially (all bits disabled). When the mtfsb1 instruction is > executed, the ZE bit is set. I ran this program twice. Once with the mtfsb1 > line uncommented, and another time with the line commented. The result for > the answer was different in each situation. > > #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; > //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; > } > > > -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature