www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D on x86-64?

reply =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
What parts of DMD/GDC and GPhobos/Phobos have to be fixed
before AMD64's 64bit mode can be used by D applications?

Thomas
Sep 20 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <dgokp9$mda$1 digitaldaemon.com>, =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?=
says...
What parts of DMD/GDC and GPhobos/Phobos have to be fixed
before AMD64's 64bit mode can be used by D applications?
For Phobos, inline asm referring to memory addresses will need the register labels changed: E*X to R*X. That's all I know of on the library end. Sean
Sep 20 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
news:dgokp9$mda$1 digitaldaemon.com...
 What parts of DMD/GDC
Needs a new code generator, linker, librarian, obj2asm, and inline assembler. I can probably get that done next weekend <g>.
 and GPhobos/Phobos have to be fixed
 before AMD64's 64bit mode can be used by D applications?
The inline assembler code will be most of it.
Sep 20 2005
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Walter Bright wrote:
 "Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
 news:dgokp9$mda$1 digitaldaemon.com...
 
What parts of DMD/GDC
Needs a new code generator, linker, librarian, obj2asm, and inline assembler. I can probably get that done next weekend <g>.
Seriously? I'm mislead by your <g>rin... Some (in)sane people could achieve such a thing, you know...
 
and GPhobos/Phobos have to be fixed
before AMD64's 64bit mode can be used by D applications?
The inline assembler code will be most of it.
Excuse my ignorance of GCC's internals, but is it well equipped
Sep 20 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
James Dunne wrote:
 Walter Bright wrote:
 
 "Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
 news:dgokp9$mda$1 digitaldaemon.com...

 What parts of DMD/GDC
Needs a new code generator, linker, librarian, obj2asm, and inline assembler. I can probably get that done next weekend <g>.
Seriously? I'm mislead by your <g>rin... Some (in)sane people could achieve such a thing, you know...
 and GPhobos/Phobos have to be fixed
 before AMD64's 64bit mode can be used by D applications?
The inline assembler code will be most of it.
Excuse my ignorance of GCC's internals, but is it well equipped
I don't know what happened to Thunderbird there, I hit a key and all hell broke loose and it apparently sent the message.... anyways... what I meant to say, was that I'm fairly certain that GCC's backend systems are capable of producing 64-bit code. This would imply that GDC has more of a head-start in this direction than does DMD, noting the rather large/complex list Walter gave above.
Sep 20 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"James Dunne" <james.jdunne gmail.com> wrote in message
news:dgphpk$1hsk$2 digitaldaemon.com...
 what I meant to say, was that I'm fairly certain that GCC's backend
 systems are capable of producing 64-bit code.  This would imply that GDC
 has more of a head-start in this direction than does DMD, noting the
 rather large/complex list Walter gave above.
I think you're right.
Sep 20 2005
prev sibling parent reply =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
Walter Bright schrieb:
 "Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
 news:dgokp9$mda$1 digitaldaemon.com...
 
What parts of DMD/GDC
Needs a new code generator, linker, librarian, obj2asm, and inline assembler. I can probably get that done next weekend <g>.
and GPhobos/Phobos have to be fixed
before AMD64's 64bit mode can be used by D applications?
The inline assembler code will be most of it.
I'll start the lazy route by trying to clean up the size_t/uint and ptrdiff_t/int issues in Phobos. Thomas
Sep 21 2005
next sibling parent reply =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
Thomas Kühne schrieb:
 Walter Bright schrieb:
 
"Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
news:dgokp9$mda$1 digitaldaemon.com...


What parts of DMD/GDC
Needs a new code generator, linker, librarian, obj2asm, and inline assembler. I can probably get that done next weekend <g>.
and GPhobos/Phobos have to be fixed
before AMD64's 64bit mode can be used by D applications?
The inline assembler code will be most of it.
I'll start the lazy route by trying to clean up the size_t/uint and ptrdiff_t/int issues in Phobos.
Are bit arrays going to be aligned to (size_t.sizeof * 8)= 32/64 or should they stay at 32? Is there any good reason for returning long in quite a lot places where Array* could be returned? Thomas
Sep 22 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
news:dgum8e$1gm0$1 digitaldaemon.com...
 Are bit arrays going to be aligned to (size_t.sizeof * 8)= 32/64 or
 should they stay at 32?
I don't know.
 Is there any good reason for returning long in quite a lot places where
 Array* could be returned?
No.
Sep 22 2005
prev sibling parent reply =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 I'll start the lazy route by trying to clean up the size_t/uint and
 ptrdiff_t/int issues in Phobos.
The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128) 1) array indexes Changes: int -> size_t (32 bit systems: uint; 64 bit systems: ulong) Consequence: maximum array length changed from (int.max) to (size_t.max-1) bytes Hint: use (size_t.max) instead of (-1) to indicate an invalid array index 2) Object Changes: int Object.toHash() -> size_t Object.toHash() Consequences: updated your .toHash function signatures 3) TypeInfo Changes: int Interface.offset() -> ptrdiff_t Interface.offset() int TypeInfo.tsize() -> size_t TypeInfo.tsize() Consequences: check code that uses reflection Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDNSlL3w+/yD4P9tIRAkOIAJkBlfW+XqvdlKfTn9V4rOgUwrMzgQCdGCfN FHeDq2KCr8ksp7ZD7AsWpzg= =QSOi -----END PGP SIGNATURE-----
Sep 24 2005
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
news:dh39av$6ic$1 digitaldaemon.com...
 The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)

 1) array indexes
 Changes:
 int -> size_t
 (32 bit systems: uint; 64 bit systems: ulong)
 Consequence:
 maximum array length changed from (int.max) to
 (size_t.max-1) bytes
 Hint:
 use (size_t.max) instead of (-1) to indicate an
 invalid array index
Yes.
 2) Object
 Changes:
 int Object.toHash() -> size_t Object.toHash()
 Consequences:
 updated your .toHash function signatures
I don't think that one is necessary. The low 32 bits of an address will do fine as a hash.
 3) TypeInfo
 Changes:
 int Interface.offset() -> ptrdiff_t Interface.offset()
 int TypeInfo.tsize() -> size_t TypeInfo.tsize()
 Consequences:
 check code that uses reflection
Yes.
Sep 24 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 "Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
 news:dh39av$6ic$1 digitaldaemon.com...
 
The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)
2) Object
Changes:
int Object.toHash() -> size_t Object.toHash()
Consequences:
updated your .toHash function signatures
I don't think that one is necessary. The low 32 bits of an address will do fine as a hash.
At first I thought staying with 32b hashing is daring. Then I thought, well, (a theoretical upper limit of) 4 billion buckets ought to be plenty. But consider: 32b hashing, some years from now, would be exactly the same as if we had 16b hashing now. (I assume we all agree on this.) One would think that 65 thousand buckets ought to be enough for anything today. Now, if the allocator aligns to ceil(log2(size)), as I think it does, then objects of size 10kB never get to use the 14 lowest bits? That would leave us with 2 bits (equalling 4 buckets), with the 16b hash I'm using as example. So 16b hashing would be pathetic today. Analogically, 32b hashing has to be equally pathetic on D day. ------------ Totally separate from this, we should promise not to use fixed sizes in things related to architecture. Painting ourselves in the corner now is bad, but the day we get 128b machines, it'll be a disaster. Changing fundamental signatures that day is plain impossible. (I hear folks crying 64b will last for the next 20 years. I feel I agree. But then I felt like this when we got 32b. And when the PC came with 16b. At that time I was totally comfortable with 8b machines doing text processing, databases, spreadsheets, and accounting.) What's 20 years in a language's life? Nothing. (Ahhh: unless we think small now!) ------------ Before anybody else gets smart and proposes a genius workaround for 64b architectures, here it is: int Object.toHash could return its position shifted to right ceil(log2(mySize)) bits. Cute as this may seem, it's a kludge. And returning int still won't grow with architecture -- only pushing the snow in front of us further ahead, slowly becoming a mountain.
Sep 25 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <4336A712.7060305 nospam.org>, Georg Wrede says...
Walter Bright wrote:
 "Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
 news:dh39av$6ic$1 digitaldaemon.com...
 
The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)
2) Object
Changes:
int Object.toHash() -> size_t Object.toHash()
Consequences:
updated your .toHash function signatures
I don't think that one is necessary. The low 32 bits of an address will do fine as a hash.
At first I thought staying with 32b hashing is daring. Then I thought, well, (a theoretical upper limit of) 4 billion buckets ought to be plenty.
Not necessarily. Implementors tend to use probing hash tables in instances where memory is at a premium (ie. when they expect the hash table to be extremely large) and this approach necessitates N buckets. So while I agree that it's unlikely, I'm not sure I'd be willing to assert that no one would ever want to store more than 4 billion elements at once. After all, arrays have size_t length. Sean
Sep 25 2005
prev sibling parent =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Georg Wrede schrieb:
 
 
 Walter Bright wrote:
 
 "Thomas Kühne" <thomas-dloop kuehne.cn> wrote in message
 news:dh39av$6ic$1 digitaldaemon.com...

 The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128)
 2) Object
 Changes:
 int Object.toHash() -> size_t Object.toHash()
 Consequences:
 updated your .toHash function signatures
I don't think that one is necessary. The low 32 bits of an address will do fine as a hash.
 Totally separate from this, we should promise not to use fixed sizes in
 things related to architecture. Painting ourselves in the corner now is
 bad, but the day we get 128b machines, it'll be a disaster. Changing
 fundamental signatures that day is plain impossible.
 Before anybody else gets smart and proposes a genius workaround for 64b
 architectures, here it is:
 
 int Object.toHash could return its position shifted to right
 ceil(log2(mySize)) bits.
 
 Cute as this may seem, it's a kludge. And returning int still won't grow
 with architecture -- only pushing the snow in front of us further ahead,
 slowly becoming a mountain.
Thanks George for the nice summary. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDN5WC3w+/yD4P9tIRApflAJ9Yr9BNDfNF1O0D89ZbaWl7CJ5DxQCfZvDm tB8zl1lkl2sXUukjug+0NsI= =KdlB -----END PGP SIGNATURE-----
Sep 25 2005
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dh39av$6ic$1 digitaldaemon.com>, =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?=
says...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 I'll start the lazy route by trying to clean up the size_t/uint and
 ptrdiff_t/int issues in Phobos.
The current state of affairs for GPhobos (based on gdc-0.15/dmd 0.128) 1) array indexes Changes: int -> size_t (32 bit systems: uint; 64 bit systems: ulong) Consequence: maximum array length changed from (int.max) to (size_t.max-1) bytes Hint: use (size_t.max) instead of (-1) to indicate an invalid array index 2) Object Changes: int Object.toHash() -> size_t Object.toHash() Consequences: updated your .toHash function signatures 3) TypeInfo Changes: int Interface.offset() -> ptrdiff_t Interface.offset() int TypeInfo.tsize() -> size_t TypeInfo.tsize() Consequences: check code that uses reflection Thomas
First off - thanks for putting the time into this. Just wondering though - might it not be better to do this on the latest version of phobos that comes with DMD, so Walter can apply the patch to that (and then the next version of GDC will inherit that anyhow)? Or will the patch file apply equally well to the latest version as-is? Thanks, - Dave
-----BEGIN PGP SIGNATURE-----

iD8DBQFDNSlL3w+/yD4P9tIRAkOIAJkBlfW+XqvdlKfTn9V4rOgUwrMzgQCdGCfN
FHeDq2KCr8ksp7ZD7AsWpzg=
=QSOi
-----END PGP SIGNATURE-----
Sep 25 2005
parent reply =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave schrieb:
 Just wondering though - might it not be better to do this on the latest version
 of phobos that comes with DMD, so Walter can apply the patch to that (and then
 the next version of GDC will inherit that anyhow)?

 Or will the patch file apply equally well to the latest version as-is?
I did start with Phobos but realized soon that GPhobos is much easier to port. One of the testing platforms is Win32 compiled with dmc, dmd and win32.mak, so you can use GPhobos with "pure" DMD. Featurewise GPhpobos-0.15 and Phobos-0.133 aren't that far apart, thus updating the application visibile features is manageable. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFDN5TR3w+/yD4P9tIRAs5bAJ9Vw/UeS+LqZ69GGMD/CCaxF7wUZQCghwVr Md3glIjE1wsVCmbwlCoIt70= =lqMg -----END PGP SIGNATURE-----
Sep 25 2005
parent reply =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
[Follow up set to D.gnu]

Here comes a first try to clean up Phobos' 32bit-ism.
The code is based on GDC-0.15's GPhobos and should be featurewise - with
the exception of std.math - behave identical to DMD-0.133's Phobos.

As I haven't yet figured out the nasty bug during module initialization
on Linux systems, I can only post a precompiled phobos.lib for 32bit
Windows.

If you have a bit time, please relink your applications with this
patched Phobpos to help locate all those porting bugs, thanks.

WARNING: this is a very alpha stage and not save for production
Especially std.regex and opApply haven't yet been dealt with.

precompiled:
http://gphobos64.kuehne.cn/lib32/

sources: (subversion)
http://gphobos64.kuehne.cn/phobos/

Thomas
Sep 27 2005
parent =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> writes:
Has anybody an Idea why
    Object[] o = new Object[1];
could result in
    _d_new(length:4, size:134813823)

Thomas


GC log for GPhobos and DMD 0.134 on Linux below:


_d_newclass(ci = 0x80a00b4, name= Object)

************Gcx::newPool(npages = 1)****************
 p = 0x401c8ff0
p = 0x401c8ff0
ci = 0x80a00b4, ci.init = 0x8, len = 134811439
vptr = 0x8090f3f
vtbl[0] = 0x80a00b4
vtbl[1] = 0x805495c
init[0] = 8090f3f
init[1] = 0
init[2] = 656a624f
init[3] = 7463
init[4] = 80a00b4

_d_newclass(ci = 0x80a5ef0, name= Thread)
 p = 0x401c9fc0
p = 0x401c9fc0
ci = 0x80a5ef0, ci.init = 0x30, len = 134869136
vptr = 0x809f0c8
vtbl[0] = 0x80a5ef0
vtbl[1] = 0x805495c
init[0] = 809f0c8
init[1] = 0
init[2] = 0
init[3] = 0
init[4] = 0


Object[] o = new Object[1]; // Object.sizeof:4 _d_new(length:4, size:134813823) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ************Gcx::newPool(npages = 131655)**************** _d_newclass(ci = 0x80a5c68, name= AssertError) p = 0x401cafe0 p = 0x401cafe0 ci = 0x80a5c68, ci.init = 0x20, len = 134867734 vptr = 0x809eb42 vtbl[0] = 0x80a5c68 vtbl[1] = 0x8055654 init[0] = 809eb42 init[1] = 0 init[2] = 0 init[3] = 0 init[4] = 0 Error: AssertError Failure gcx(1218)
Sep 30 2005