www.digitalmars.com         C & C++   DMDScript  

D.gnu - GDC for x86_64!

reply Gregor Richards <Richards codu.org> writes:
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
Sep 20 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Sep 21 2006
parent reply Don Clugston <dac nospam.com.au> writes:
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); }
Sep 21 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
parent Don Clugston <dac nospam.com.au> writes:
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).
Sep 21 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
prev sibling next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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-----
Sep 21 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Sep 21 2006
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
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
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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