• =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> Sep 20 2005
• Sean Kelly <sean f4.ca> Sep 20 2005
• "Walter Bright" <newshound digitalmars.com> Sep 20 2005
• James Dunne <james.jdunne gmail.com> Sep 20 2005
• James Dunne <james.jdunne gmail.com> Sep 20 2005
• "Walter Bright" <newshound digitalmars.com> Sep 20 2005
• =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> Sep 21 2005
• =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> Sep 22 2005
• "Walter Bright" <newshound digitalmars.com> Sep 22 2005
• =?UTF-8?B?VGhvbWFzIEvDvGhuZQ==?= <thomas-dloop kuehne.cn> Sep 24 2005
• "Walter Bright" <newshound digitalmars.com> Sep 24 2005
• Georg Wrede <georg.wrede nospam.org> Sep 25 2005
• Sean Kelly <sean f4.ca> Sep 25 2005
• =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> Sep 25 2005
• Dave <Dave_member pathlink.com> Sep 25 2005
• =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> Sep 25 2005
• =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> Sep 27 2005
• =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.cn> Sep 30 2005

What parts of DMD/GDC and GPhobos/Phobos have to be fixed
before AMD64's 64bit mode can be used by D applications?

Thomas

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

"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.

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

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.

"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.

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

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

"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.

-----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-----

"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.

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.

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

-----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-----

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-----

-----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-----

[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

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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




























































































_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)