Thread overview | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
September 20, 2005 D on x86-64? | ||||
---|---|---|---|---|
| ||||
What parts of DMD/GDC and GPhobos/Phobos have to be fixed before AMD64's 64bit mode can be used by D applications? Thomas |
September 20, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Kühne | 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 |
September 20, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Kühne | "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. |
September 20, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
September 20, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to James Dunne | 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.
|
September 20, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to James Dunne | "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. |
September 21, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
September 22, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Kühne | 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
|
September 22, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Kühne | "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. |
September 24, 2005 Re: D on x86-64? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Thomas Kühne Attachments: | > 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
|
Copyright © 1999-2021 by the D Language Foundation