D.gnu - GDC for x86_64!
- Gregor Richards (12/12) Sep 20 2006 (I'm dual-posting this to both D.gnu and digitalmars.D, since it's at
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (4/13) Sep 21 2006 I am testing on Fedora Core 5 PowerPC, multi-lib ppc64 and ppc system.
- Don Clugston (38/56) Sep 21 2006 Anders, could you do me a favour? I'd love to know what the following
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (15/19) Sep 21 2006 Here you go: (PPC)
- Don Clugston (10/33) Sep 21 2006 Thanks! That's fascinating, the last two lines is a real surprise
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (5/7) Sep 21 2006 If you are doing further development, the easiest is
- Thomas Kuehne (23/34) Sep 21 2006 -----BEGIN PGP SIGNED MESSAGE-----
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (13/23) Sep 21 2006 Did you have a patch for those ? Think I saw the same on PPC64,
- Gregor Richards (3/3) Sep 25 2006 FYI, I am planning on getting back to this (getting it stable and
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (9/11) Sep 25 2006 I am revising the GDC spec so that it works for PPC64 too, based on
(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
Sep 20 2006
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 systemI am testing on Fedora Core 5 PowerPC, multi-lib ppc64 and ppc system. --anders
Sep 21 2006
Anders F Björklund wrote:Gregor Richards 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. --------- 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); }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 systemI am testing on Fedora Core 5 PowerPC, multi-lib ppc64 and ppc system. --anders
Sep 21 2006
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
Sep 21 2006
Anders F Björklund wrote:Don Clugston wrote: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??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 fff8000000000009BTW "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).
Sep 21 2006
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
Sep 21 2006
-----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 systemtested 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;< d/phobos/internal/mars.h:31: size_t 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-----
Sep 21 2006
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.dDid 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
Sep 21 2006
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
Sep 25 2006
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.
Sep 25 2006