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.

> 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