• Gregor Richards <Richards codu.org> Sep 20 2006
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Sep 21 2006
• Don Clugston <dac nospam.com.au> Sep 21 2006
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Sep 21 2006
• Don Clugston <dac nospam.com.au> Sep 21 2006
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Sep 21 2006
• Thomas Kuehne <thomas-dloop kuehne.cn> Sep 21 2006
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Sep 21 2006
• Gregor Richards <Richards codu.org> Sep 25 2006
• =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> Sep 25 2006

Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

(I'm dual-posting this to both D.gnu and digitalmars.D, since it's at 
least somewhat relevent in both)

I've made a (mostly untested) port of GDC 0.19 to x86_64.

This required numerous patches to the frontend, and a few less patches 
to phobos.  I have another thread in digitalmars.D complaining about the 
phobos patches.

Attached is a patch file for GDC 0.19.  Testers are welcome, I've only 
done some very simple "does this work at all" tests.

  - Gregor Richards

PS: I've only tested this on an emulated x86_64 system

PPS: I've only tested this with --disable-multilib, as I was on a Debian 
system

Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gregor Richards wrote:

 I've made a (mostly untested) port of GDC 0.19 to x86_64.
 
 This required numerous patches to the frontend, and a few less patches 
 to phobos.  I have another thread in digitalmars.D complaining about the 
 phobos patches.
 
 Attached is a patch file for GDC 0.19.  Testers are welcome, I've only 
 done some very simple "does this work at all" tests.


Sounds fun, I'm going to try it on PPC64. Attaching missing platform.

 PS: I've only tested this on an emulated x86_64 system


I am testing on Fedora Core 5 PowerPC, multi-lib ppc64 and ppc system.

--anders

Anders F Björklund wrote:
 Gregor Richards wrote:
 
 I've made a (mostly untested) port of GDC 0.19 to x86_64.

 This required numerous patches to the frontend, and a few less patches 
 to phobos.  I have another thread in digitalmars.D complaining about 
 the phobos patches.

 Attached is a patch file for GDC 0.19.  Testers are welcome, I've only 
 done some very simple "does this work at all" tests.


 Sounds fun, I'm going to try it on PPC64. Attaching missing platform.
 
 PS: I've only tested this on an emulated x86_64 system


 I am testing on Fedora Core 5 PowerPC, multi-lib ppc64 and ppc system.
 
 --anders


Anders, could you do me a favour? I'd love to know what the following 
prints on a PowerPC CPU (and on x86-64, for that matter). It would be a 
great help for math library portability. It's amazingly hard to find 
documentation on this stuff. - Don.
---------
import std.stdio;

void show(double x)
{
     writefln("%f %08x", x, *cast(ulong*)&x);
}

void main()
{
     double x = double.init;
     double zero = 0.0;
     show(x);
     x = real.nan;
     show(x);
     ulong *p = cast(ulong *)&x;
     *p = 0xFFFF_FFFF_FFFF_FFFF;
     show(x);
     float f = x*5.2f;
     show(f);
     *p = 0xFFFF_ABCD_9876_FFFF;
     show(x);
     f = x;
     show(f);
     x = 35.61;
     x /= zero;
     show(x);
     x *= zero;
     show(x);
     x = 56.37;
     double y = x % zero;
     show(y);
     x = -y;
     show(x);
}

Don Clugston wrote:

 Anders, could you do me a favour? I'd love to know what the following 
 prints on a PowerPC CPU (and on x86-64, for that matter). It would be a 
 great help for math library portability. It's amazingly hard to find 
 documentation on this stuff. - Don.


Here you go: (PPC)
nan 7ff8000000000000
nan 7ff8000000000000
nan ffffffffffffffff
nan ffffffffe0000000
nan ffffabcd9876ffff
nan ffffabcd80000000
inf 7ff0000000000000
nan 7ff8000000000000
nan 7ff8000000000009
nan fff8000000000009

BTW "real" and "double"
are the same size here.

--anders

Anders F Björklund wrote:
 Don Clugston wrote:
 
 Anders, could you do me a favour? I'd love to know what the following 
 prints on a PowerPC CPU (and on x86-64, for that matter). It would be 
 a great help for math library portability. It's amazingly hard to find 
 documentation on this stuff. - Don.


 Here you go: (PPC)
 nan 7ff8000000000000
 nan 7ff8000000000000
 nan ffffffffffffffff
 nan ffffffffe0000000
 nan ffffabcd9876ffff
 nan ffffabcd80000000
 inf 7ff0000000000000
 nan 7ff8000000000000
 nan 7ff8000000000009
 nan fff8000000000009


Thanks! That's fascinating, the last two lines is a real surprise 
(totally different to the x86 behaviour). Where the heck did that '9' 
come from??

 BTW "real" and "double"
 are the same size here.


Yes, that's part of the reason for my interest in it. It's BigEndian 
too, isn't it?


 If you are doing further development, the easiest is
 probably to get a full PowerPC emulator environment ?

 Like this one, for instance: http://pearpc.sf.net/


I know about PearPC, but what I was testing just then is the least 
likely part of the CPU emulation to be tested properly; I reckon that if 
they got that wrong, it wouldn't break any code. (I bet it doesn't give 
those '9's).

Don Clugston wrote:

 It would be a great help for math library portability.
 It's amazingly hard to find documentation on this stuff.


If you are doing further development, the easiest is
probably to get a full PowerPC emulator environment ?

Like this one, for instance: http://pearpc.sf.net/

--anders

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gregor Richards schrieb am 2006-09-21:
 (I'm dual-posting this to both D.gnu and digitalmars.D, since it's at 
 least somewhat relevent in both)

 I've made a (mostly untested) port of GDC 0.19 to x86_64.

 This required numerous patches to the frontend, and a few less patches 
 to phobos.  I have another thread in digitalmars.D complaining about the 
 phobos patches.

 Attached is a patch file for GDC 0.19.  Testers are welcome, I've only 
 done some very simple "does this work at all" tests.

   - Gregor Richards

 PS: I've only tested this on an emulated x86_64 system


tested compiler:
gcc (GCC) 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)
   (gdc 0.19, using dmd 0.162)

Additional fix:
 d/phobos/internal/mars.h:31: unsigned monitor;



I had to disable some code in the following files due to
"internal compiler error: in copy_to_mode_reg, at explow.c:691"
"internal compiler error: in emit_move_insn, at expr.c:2830"
"internal compiler error: in expand_expr_real, at expr.c:6525"

d/phobos/std/file.d
d/phobos/std/string.d
d/phobos/std/regexp.d
d/phobos/std/format.d
d/phobos/std/zip.d

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFFElsnLK5blCcjpWoRAvwPAJ4285GvafSzN9Jc7Te+j04MbaoSmwCfVbro
xPAsQIq/IokZQsB7QgWGbts=
=reBj
-----END PGP SIGNATURE-----

Thomas Kuehne wrote:

 I had to disable some code in the following files due to
 "internal compiler error: in copy_to_mode_reg, at explow.c:691"
 "internal compiler error: in emit_move_insn, at expr.c:2830"
 "internal compiler error: in expand_expr_real, at expr.c:6525"
 
 d/phobos/std/file.d
 d/phobos/std/string.d
 d/phobos/std/regexp.d
 d/phobos/std/format.d
 d/phobos/std/zip.d


Did you have a patch for those ? Think I saw the same on PPC64,
for the std.string "abbrev" but didn't encounter the others...


I just did a version() and a assert(0), to disable ICE sections:

version (PPC64)
{
assert(0); // "internal compiler error: in copy_to_mode_reg, at 
explow.c:581"
}
else

Think you could do the same workaround for the five issues above ?
(depending on whether it was in a commonly used function or not...)

--anders

FYI, I am planning on getting back to this (getting it stable and 
proper), but am swamped right now with other things (some D related :P )

  - Gregor Richards

Gregor Richards wrote:

 FYI, I am planning on getting back to this (getting it stable and 
 proper), but am swamped right now with other things (some D related :P )


I am revising the GDC spec so that it works for PPC64 too, based on
the GCC spec for Fedora Core 4 (it needs both of PPC and PPC64, just
like it needs both of SPARC and SPARC64 - for Intel those are separate
in two versions: "i386" and "x86_64", but not so on the RISC chips...)

So it does compile, but needs some love before it can be tested.

--anders

PS. The regular FC5 GCC uses GCC 4.1.x with some "neat features",
     so it's better to use the FC4 GCC which is 4.0.x and plainer.