Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
Hi all, As part of my work on QEMU I regularly test various PPC images, and I've discovered that the latest debian ports powerpc image from https://cdimage.debian.org/cdimage/ports/9.0/powerpc/iso-cd/ doesn't appear to work under QEMU: $ ./qemu-system-ppc -cdrom debian-9.0-powerpc-NETINST-1.iso -boot d -M mac99 -nographic >> = >> OpenBIOS 1.1 [Jan 26 2018 07:53] >> Configuration device id QEMU version 1 machine id 1 >> CPUs: 1 >> Memory: 128M >> UUID: ---- >> CPU type PowerPC,G4 milliseconds isn't unique. Welcome to OpenBIOS v1.1 built on Jan 26 2018 07:53 Trying cd:,\\:tbxi... (set-color errors cut as not important) :-1,: Unable to open file, Invalid device Can't open config file Welcome to yaboot version 1.3.17 boot: My existing Jessie test image (debian-8.5.0-powerpc-netinst.iso) works fine, so it looks like there is a regression somewhere in the boot loader configuration. Does anyone know what has changed between these two images that could cause this to break? ATB, Mark.
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
Hi Mark, On 02/10/2018 10:22 AM, Mark Cave-Ayland wrote: $ ./qemu-system-ppc -cdrom debian-9.0-powerpc-NETINST-1.iso -boot d -M mac99 -nographic [...] Trying cd:,\\:tbxi... [...] :-1,: Unable to open file, Invalid device Can't open config file Welcome to yaboot version 1.3.17 boot: My existing Jessie test image (debian-8.5.0-powerpc-netinst.iso) works fine, so it looks like there is a regression somewhere in the boot loader configuration. Does anyone know what has changed between these two images that could cause this to break? No, not really, but just for the record, on real hardware (a Mac mini G4 in this case) the current ISO from 2018-02-07 20:35h works as expected: ``` ok 0 > boot cd:,\\:tbxi load-size=806 adler32=96ebe7f0 parsing evaluating This is a Debian installation CDROM, built on 20180207-19:20 Press ENTER to continue, or press TAB for a full list of options If the system fails to boot with a white screen which doesn't go away, try install video=ofonly Welcome to yaboot version 1.3.17 Enter "help" to get some basic usage information boot: ``` Assuming that it fails for you after loading/during execution of the CHRP script (`/install/ofboot.b`) you could try to compare the current version of this script with the one on the Jessie ISO. The current CHRP script seems to determine if the used CPU is 64 bit capable or not and selects the appropriate yaboot config (`/install/yaboot.conf` or `/install/mac32.conf`): ``` " screen" output load-base release-load-area " /cpus/@0" find-package if " 64-bit" rot get-package-property 0= if 2drop " boot cd:,\install\yaboot conf=cd:,\install\yaboot.conf" eval else " boot cd:,\install\yaboot conf=cd:,\install\mac32.conf" eval then then ``` And just for curiosity, what does the `conf` command print out in your case after entering it at the yaboot `boot:` prompt? Cheers, Frank
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
On 10/02/18 13:39, Frank Scheiner wrote:
Hi Mark,
On 02/10/2018 10:22 AM, Mark Cave-Ayland wrote:
$ ./qemu-system-ppc -cdrom debian-9.0-powerpc-NETINST-1.iso -boot d -M
mac99 -nographic
[...]
Trying cd:,\\:tbxi...
[...]
:-1,: Unable to open file, Invalid device
Can't open config file
Welcome to yaboot version 1.3.17
boot:
My existing Jessie test image (debian-8.5.0-powerpc-netinst.iso) works
fine, so it looks like there is a regression somewhere in the boot
loader configuration. Does anyone know what has changed between these
two images that could cause this to break?
No, not really, but just for the record, on real hardware (a Mac mini G4
in this case) the current ISO from 2018-02-07 20:35h works as expected:
```
ok
0 > boot cd:,\\:tbxi load-size=806 adler32=96ebe7f0
parsing
evaluating
This is a Debian installation CDROM,
built on 20180207-19:20
Press ENTER to continue, or press TAB for a
full list of options
If the system fails to boot with a white screen
which doesn't go away, try
install video=ofonly
Welcome to yaboot version 1.3.17
Enter "help" to get some basic usage information
boot:
```
Assuming that it fails for you after loading/during execution of the
CHRP script (`/install/ofboot.b`) you could try to compare the current
version of this script with the one on the Jessie ISO.
The current CHRP script seems to determine if the used CPU is 64 bit
capable or not and selects the appropriate yaboot config
(`/install/yaboot.conf` or `/install/mac32.conf`):
```
" screen" output
load-base release-load-area
" /cpus/@0" find-package if
" 64-bit" rot get-package-property 0= if
2drop
" boot cd:,\install\yaboot conf=cd:,\install\yaboot.conf" eval
else
" boot cd:,\install\yaboot conf=cd:,\install\mac32.conf" eval
then
then
```
And just for curiosity, what does the `conf` command print out in your
case after entering it at the yaboot `boot:` prompt?
Hi Frank,
Since I still couldn't get anywhere with typing in the above commands
into the debian 9.0 image, I rebuilt OpenBIOS with CIF debugging enabled
and attached are both console outputs for comparision.
The key difference seems to be here:
debian-8.5:
>> getprop(0xfff49014, "ibm,client-architecture-support-reboot",
0x002305e4, 4) = -1
>> getprop(0xfff49014, "ibm,fw-nbr-reboots", 0x002305e4, 4) = -1
>> getprop(0xfff49014, "boot-once", 0x002449ec, 1024) = -1
>> setprop(0xfff49014, "boot-once", 0x, 0)
>> = 0
>> finddevice("cd:,\install\mac32.conf") = 0xfff56608
>> getprop(0xfff56608, "device_type", 0xfffbaad8, 63) = 6
>> 0xfffbaad8 62 6c 6f 63 6b 00 __ __ __ __ __ __ __ __ __ __ block.
>> finddevice("cd") = 0xfff56608
>> getprop(0xfff56608, "device_type", 0xfffbab08, 63) = 6
>> 0xfffbab08 62 6c 6f 63 6b 00 __ __ __ __ __ __ __ __ __ __ block.
>> finddevice("cd") = 0xfff56608
>> getprop(0xfff56608, "device_type", 0xfffbaa48, 63) = 6
>> 0xfffbaa48 62 6c 6f 63 6b 00 __ __ __ __ __ __ __ __ __ __ block.
debian-9.0:
>> getprop(0xfff49014, "ibm,client-architecture-support-reboot",
0x00120464, 4) = -1
>> getprop(0xfff49014, "ibm,fw-nbr-reboots", 0x00120464, 4) = -1
>> getprop(0xfff49014, "boot-once", 0x0013482c, 1024) = -1
>> setprop(0xfff49014, "boot-once", 0x, 0)
>> = 0
>> finddevice("") = 0x
>> finddevice("") = 0x
>> finddevice("") = 0x
For some reason yaboot isn't parsing the conf= parameter even though it
is present in bootargs?
ATB,
Mark.
>> =
>> OpenBIOS 1.1 [Feb 10 2018 13:56]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 128M
>> UUID: ----
>> CPU type PowerPC,G4
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Feb 10 2018 13:56
0 > boot cd:,\install\yaboot conf=cd:,\install\mac32.conf >> switching to new
context:
>> finddevice("/chosen") = 0xfff4908c
>> finddevice("/options") = 0xfff49014
>> getprop(0xfff4908c, "stdout", 0x002305f4, 4) = 4
>> 0x002305f4 07 c5 aa 70 __ __ __ __ __ __ __ __ __ __ __ __ .Ūp
>> getprop(0xfff4908c, "stdin", 0x002305f8, 4) = 4
>> 0x002305f8 07 c5 ab 74 __ __ __ __ __ __ __ __ __ __ __ __ .ūt
>> getprop(0xfff4908c, "memory", 0x0023385c, 4) = 4
>> 0x0023385c 07 c5 a9 70 __ __ __ __ __ __ __ __ __ __ __ __ .ũp
>> getprop(0xfff4908c, "mmu", 0x00233758, 4) = 4
>> 0x00233758 07 c5 a7 68 __ __ __ __ __ __ __ __ __ __ __ __ .ŧh
>> of_client_interface: interpret 0021efa0
([1] -- [1])ethod ;w then ;0= ;int nip nip ;
>> handle_calls return:
>> of_client_interface: interpret 0021f018
value mmu# value mem# ([1] -- [1])ge if dup " memory" rot GPP$ if D2NIP swap "
mmu" rot GPP$ if D2NIP else 0 then else 0 0 then else 0 0 then
>> handle_calls return:
>> of_client_interface: interpret 0021f0b4
>> interpret : ^mem mem# $CM ; : ^mmu mmu# $CM ; ([1] -- [1])
>> handle_calls return:
>> claim(0x0030, 1048576, 0) = 0x0030
>> finddevice("/") = 0xfff48cac
>>
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
On 02/10/2018 10:22 AM, Mark Cave-Ayland wrote: > My existing Jessie test image (debian-8.5.0-powerpc-netinst.iso) works fine, > so it looks like there is a regression somewhere in the boot loader > configuration. > Does anyone know what has changed between these two images that could cause > this to break? Possibly relevant discussion: > https://lists.debian.org/debian-powerpc/2017/10/msg00089.html > https://lists.debian.org/debian-powerpc/2017/10/msg00118.html We should really finally switch over to GRUB. @Frank: Did you make any progress with GRUB on powerpc/ppc64? Anything you need help with? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Detecting PowerPC SPE libraries
On 02/09/2018 09:22 PM, Javier Serrano Polo wrote: > I am trying to detect PowerPC SPE libraries. The best way I find is to > check if Tag_GNU_Power_ABI_FP is soft float. Am I right? On PowerPCSPE targets, gcc will define __SPE__: root@atlantis:~> echo | gcc -E -dM - |grep -i SPE #define __SPE__ 1 root@atlantis:~> So, "#if defined(__powerpc__) && defined(__SPE__)" is what you want. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Unable to boot debian ports debian-9.0-powerpc-NETINST-1.iso image in QEMU
On 02/10/2018 03:29 PM, John Paul Adrian Glaubitz wrote: On 02/10/2018 10:22 AM, Mark Cave-Ayland wrote: My existing Jessie test image (debian-8.5.0-powerpc-netinst.iso) works fine, so it looks like there is a regression somewhere in the boot loader configuration. Does anyone know what has changed between these two images that could cause this to break? Possibly relevant discussion: https://lists.debian.org/debian-powerpc/2017/10/msg00089.html https://lists.debian.org/debian-powerpc/2017/10/msg00118.html Yeah, maybe it's just the yaboot versions (1.3.16 for Jessie, 1.3.17 for Sid), that makes the difference. We should really finally switch over to GRUB. @Frank: Did you make any progress with GRUB on powerpc/ppc64? Anything you need help with? The main issue was that I used `ofpath` which is - as I only later found out - part of the yaboot package in my patches to d-i/grub-installer from November 2017 ([1]) because it was - and still is AFAIK - the only "device-node-to-ofpath-translator" that works correctly for Power Macs (*and* also for IBM POWER machines - as we've seen in the past ([2]), `ofpathname` does not work correctly from my point of view). [1]: https://lists.debian.org/debian-powerpc/2017/11/msg00068.html [2]: https://lists.debian.org/debian-powerpc/2017/11/msg00086.html I did not follow if there was any progress made for the `grub-ofpathname` ([3]) tool. Last time I checked it didn't work correctly for Power Macs and I had the impression that this tool is tailored to sparc(64) OBP actually and not all ieee1275 implementations per se. [3]: http://git.savannah.gnu.org/cgit/grub.git/tree/util/ieee1275/grub-ofpathname.c?id=2dc163bf692c18275de7b0d6716138c676e3bf92 My personal preference would be to keep `ofpath` and either create a separate (u)deb for it (as it works for both Power Macs and IBM POWER machines and also for other PowerPC related machines (not checked because of missing hardware)) or move it to e.g. "pmac-utils". I think a tool that can be used by multiple boot loaders (yaboot, GRUB, and possibly others) to determine a device path should not necessarily be shipped with a single boot loader, but either be shipped in a separate package or a package related to its target platform. Is this realistic? For my patches I can of course also use another "device-node-to-ofpath-translator" as long as it works. Apart from that I assume only a rebase and some testing is needed to make it ready for review. Cheers, Frank
Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500
On 09/02/18 05:34 AM, John Paul Adrian Glaubitz wrote:
On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
mator on #debian-ports compiled gcc-7 for me with the attached patch.
With the resulting gcc, I compiled glibc and got a library I can use
sqrtf without running into an illegal instruction exception.
Would it be possible to get this applied by default? The resulting
binaries work on e6500, and ought to work on all supported CPUs
for the ppc64 port.
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
I can take the exact same source of a trivial floating point test and
drop it on very very old sparc as well as a system running very up to
date Red Hat Enterprise Linux 7.4 with AMD Opterons. Also this old mac
g5 with its PPC970MP processors where I see wildly different results on
all of them. When I say "wildly" I mean to say that the in memory data
isn't even remotely the same given the same constant inputs. I know that
the x86 hardware is somewhat crippled ( a strange ten byte format ) in
this regard but I was quite surprised by what happens on the PPC970MP
processors when compared to sparc. Regardless what compiler I use on
the sparc ( very very old Sun and much newer Fujitsu ) with Solaris 10
I always get nearly perfect results. The Debian PPC970MP produces close
results but again the in memory data is quite different.
In any case there are people out there messing with these things for
various reasons ( educational even in that I do teach ) and it is quite
weird to have to say to a student that in the year 2018 don't expect
similar results across different machines when it comes to doing any
floating point math.
Dennis
ps: long boring stuff follows where numbers don't quite work
and libquadmath seems to be out of the question.
- feel free to compile this on anything and show results --
#define _XOPEN_SOURCE 600
#include
#include
#include
#include
#include
int main (int argc, char* argv[]){
int j;
struct utsname uname_data;
long double theta, pi, approx_pi, one_over_sqrt2, ld_error;
setlocale( LC_MESSAGES, "C" );
if ( uname( &uname_data ) < 0 ) {
fprintf ( stderr,
"WARNING : Could not attain system uname data.\n" );
perror ( "uname" );
} else {
printf ("system name = %s\n", uname_data.sysname );
printf (" node name = %s\n", uname_data.nodename );
printf ("release = %s\n", uname_data.release );
printf ("version = %s\n", uname_data.version );
printf ("machine = %s\n", uname_data.machine );
}
printf ("\n");
/* plenty of digits well past the precision of binary128 */
pi = 3.1415926535897932384626433832795028841971693993751L;
printf("sizeof(long double) = %2i\n", sizeof(long double));
printf(" pi may be %+40.38Lf\n", pi);
printf("reference val = ");
printf("+3.1415926535897932384626433832795028841971693993751\n\n");
printf("%p : ", &pi);
for ( j=0; jdc@n0$ /usr/local/gcc6/bin/gcc -m64 -std=iso9899:1999 -Wfatal-errors
-pedantic-errors -o s s.c -lm
dc@n0$ ./s
system name = SunOS
node name = node000
release = 5.10
version = Generic_150400-59
machine = sun4u
sizeof(long double) = 16
pi may be +3.14159265358979323846264338327950279748
reference val = +3.1415926535897932384626433832795028841971693993751
7fffeed0 : 40 00 92 1f b5 44 42 d1 84 69 89 8c c5 17 01 b8
ld_error = +0.00
sinl(pi) may be +0.008672
approx_pi = +3.14159265358979
Re: Hardware info in Mac Mini G4
On 09/02/18 08:34 AM, Mathieu Malaterre wrote: > Just for posterity... PowerMac G5 here : ppc_nix$ hexdump -C /sys/firmware/devicetree/base/rom@0,ff80/boot-rom@fff0/BootROM-version 24 30 30 30 35 2e 32 37 66 31 00 |$0005.27f1.| 000b ppc_nix$ ppc_nix$ hexdump -C /sys/firmware/devicetree/base/serial-number 52 37 30 00 00 00 00 00 00 00 00 00 00 47 38 35 |R70..G85| 0010 34 36 41 37 4b 52 37 30 00 00 00 00 00 00 00 00 |46A7KR70| 0020 00 00 00 00 00 00 00 00 00 00 00 |...| 002b ppc_nix$ not sure what to do with that data .. but there it is. Dennis
Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500
On Sat, Feb 10, 2018 at 04:02:36PM -0500, Dennis Clarke wrote:
> On 09/02/18 05:34 AM, John Paul Adrian Glaubitz wrote:
> > On 02/09/2018 11:30 AM, Bas Vermeulen wrote:
> > > mator on #debian-ports compiled gcc-7 for me with the attached patch.
> > > With the resulting gcc, I compiled glibc and got a library I can use
> > > sqrtf without running into an illegal instruction exception.
> > >
> > > Would it be possible to get this applied by default? The resulting
> > > binaries work on e6500, and ought to work on all supported CPUs
> > > for the ppc64 port.
> >
> > 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
>
>
> I can take the exact same source of a trivial floating point test and
> drop it on very very old sparc as well as a system running very up to
> date Red Hat Enterprise Linux 7.4 with AMD Opterons. Also this old mac
> g5 with its PPC970MP processors where I see wildly different results on
> all of them. When I say "wildly" I mean to say that the in memory data
> isn't even remotely the same given the same constant inputs. I know that
> the x86 hardware is somewhat crippled ( a strange ten byte format ) in
> this regard but I was quite surprised by what happens on the PPC970MP
> processors when compared to sparc. Regardless what compiler I use on
> the sparc ( very very old Sun and much newer Fujitsu ) with Solaris 10
> I always get nearly perfect results. The Debian PPC970MP produces close
> results but again the in memory data is quite different.
>
> In any case there are people out there messing with these things for
> various reasons ( educational even in that I do teach ) and it is quite
> weird to have to say to a student that in the year 2018 don't expect
> similar results across different machines when it comes to doing any
> floating point math.
>
> Dennis
>
> ps: long boring stuff follows where numbers don't quite work
> and libquadmath seems to be out of the question.
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.
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).
For more details, you may have a look at:
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format
there is even a full paragraph on the double-double arithmetic.
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.
Cheers,
Gabriel
>
> - feel free to compile this on anything and show results --
>
> #define _XOPEN_SOURCE 600
>
> #include
> #include
> #include
> #include
> #include
>
> int main (int argc, char* argv[]){
>
> int j;
> struct utsname uname_data;
> long double theta, pi, approx_pi, one_over_sqrt2, ld_error;
>
> setlocale( LC_MESSAGES, "C" );
> if ( uname( &uname_data ) < 0 ) {
> fprintf ( stderr,
> "WARNING : Could not attain system uname data.\n" );
> perror ( "uname" );
> } else {
> printf ("system name = %s\n", uname_data.sysname );
> printf (" node name = %s\n", u
Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500
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. Dennis
