On Sun, Feb 11, 2018 at 4:30 AM, Dennis Clarke <d...@oetec.com> wrote: > >>>> This is something that needs to be discussed. A single user alone >>>> shouldn't >>>> warrant such major change in a port. You always have to keep in mind >>>> that >>>> changing the default compiler options also has potential impact on the >>>> performance on more modern ppc64 systems like Apple Macintosh. >>> >>> >>> >>> Not sure how modern an Apple Mac is but here is a photo I took only a >>> few minutes ago: >>> >>> https://i.imgur.com/6UbviKb.jpg >>> >>> >>> I have this old Mac G5 running as a fine example of a big-endian machine >>> and the PPC970MP processors in it seem to work very well. However it is >>> certainly becoming difficult to get results from it that can compare to >>> what I get from some other machines like Fujitsu SPARC for example. The >>> biggest complaint is with floating point wherein the data representation >>> may be actual IEEE 754-2008 style or some new IBM variant that I am not >>> at all familiar with. In fact, some code, trivial, won't compile at all >>> if I try to use "IEEE extended precision long double" with very few ways >>> to get around that : >>> >>> gcc -mcpu=970 -mno-altivec -m64 -std=iso9899:1999 -Wfatal-errors \ >>> -pedantic-errors -mabi=ieeelongdouble ... >>> >>> The gcc that I am using claims to be : >>> >>> GNU C99 (Debian 7.2.0-17) version 7.2.1 20171205 (powerpc64-linux-gnu) >>> compiled by GNU C version 7.2.1 20171205, GMP version 6.1.2, >>> MPFR version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP >>> >>> ... snip ... > > >> This is quite well known, for a long time, IBM on Power (not on >> mainframes) used a non IEEE format for long doubles. Actually these are >> two IEEE doubles "concatenated", so: >> - the mantissa is somewhat less precise, 2 times 53 bits instead of 112 >> - the exponent range is way smaller, in powers of 10 the range is >> roughly ±308 (same as double) instead of ±4932. > > > That seems to make sense looking at the in memory values. I can't make > heads or tails out of it in terms of IEEE754-2008 formats. As for the > IBM mainframes, well gee, that is a long lost love of mine as I was an > IBM systems admin for the 3090 MVS/ESA systems and they were a real joy > with Fortran IV. A million years ago. > >> >> The fact the the in memory representation is completely different is not >> surprising when you take this into account. >> >> This was somewhat faster than a full emulation of IEEE quad math, but >> now IBM has switched to real IEEE quad (in hardware even on Power9, I >> suspect most Sparc do it in software). > > > I can assure you that every sparc does it in software emulation. The > 64-bit floating point is pure hardware and works very well. > >> I'm away from my Power machine right now and it is switched off, so I >> can't try your code and play with compiler options. >> > > Thank you for getting back to me and I look forwards to seeing what your > IBM Power system has to say from that code snippit.
One shorted example from SO recently: const constexpr long double DEGREE_TO_RAD = 0.0174532925199432954743716805978693; const constexpr long double RAD_TO_DEGREE = 1. / DEGREE_TO_RAD; https://stackoverflow.com/questions/48553127/error-with-long-doubles-on-powerpc-when-compiling-with-gcc
