I saw Walter's latest checkin for DMD and needless to say, I'm extremely excited.  Is there an incomplete version of 64-bit DMD available yet that will do all frontend-related stuff assuming void*.sizeof == 8, size_t.sizeof == 8, etc. and then skip the codegen?  I would like to run it on the libraries that I use/develop (Phobos, dstats, parallelfuture) to have it check whether there are any issues related to improper assumptions about things like the size of pointers and size_t's and start fixing them now if there are any, so that when 64-bit support is complete these libs are ready to go.

David Simcha wrote:
> I saw Walter's latest checkin for DMD and needless to say, I'm extremely excited.  Is there an incomplete version of 64-bit DMD available yet that will do all frontend-related stuff assuming void*.sizeof == 8, size_t.sizeof == 8, etc. and then skip the codegen?  I would like to run it on the libraries that I use/develop (Phobos, dstats, parallelfuture) to have it check whether there are any issues related to improper assumptions about things like the size of pointers and size_t's and start fixing them now if there are any, so that when 64-bit support is complete these libs are ready to go.
>

It'll be a while yet. But I don't anticipate much problem with Phobos, just the inline assembly has to be reviewed.

On Jun 30, 2010, at 6:57 PM, Walter Bright wrote:
> 
> David Simcha wrote:
>> I saw Walter's latest checkin for DMD and needless to say, I'm extremely excited.  Is there an incomplete version of 64-bit DMD available yet that will do all frontend-related stuff assuming void*.sizeof == 8, size_t.sizeof == 8, etc. and then skip the codegen?  I would like to run it on the libraries that I use/develop (Phobos, dstats, parallelfuture) to have it check whether there are any issues related to improper assumptions about things like the size of pointers and size_t's and start fixing them now if there are any, so that when 64-bit support is complete these libs are ready to go.
>> 
> 
> It'll be a while yet. But I don't anticipate much problem with Phobos, just the inline assembly has to be reviewed.

What about the ABI changes for 64-bit?  Will function calls simply switch to stuffing the first arg into RAX instead of EAX and continue as-is?  Or is it too early to say?  I know the C calling convention is significantly different.

Sean Kelly wrote:
>
>
> What about the ABI changes for 64-bit?  Will function calls simply switch to stuffing the first arg into RAX instead of EAX and continue as-is?  Or is it too early to say?  I know the C calling convention is significantly different.
>
> 

I intend to match the C 64 bit ABI. But that shouldn't affect D source code other than inline asm. The only problems D source code should have are:

1. failure to account for changes in size_t and pointers
2. use of int and unsigned as indices for arrays that might get large
3. inline assembler (of course)
4. C header differences and differences in the C runtime library

If someone wants to get a head start on this, I'd start by reviewing the D files that interface with C, such as core.stdc.* and core.sys.* The system structs like _iobuf are surely different.

On Jun 30, 2010, at 9:39 PM, Walter Bright wrote:
> 
> Sean Kelly wrote:
>> 
>> 
>> What about the ABI changes for 64-bit?  Will function calls simply switch to stuffing the first arg into RAX instead of EAX and continue as-is?  Or is it too early to say?  I know the C calling convention is significantly different.
>> 
>> 
> 
> I intend to match the C 64 bit ABI. But that shouldn't affect D source code other than inline asm. The only problems D source code should have are:
> 
> 1. failure to account for changes in size_t and pointers
> 2. use of int and unsigned as indices for arrays that might get large
> 3. inline assembler (of course)
> 4. C header differences and differences in the C runtime library
> 
> If someone wants to get a head start on this, I'd start by reviewing the D files that interface with C, such as core.stdc.* and core.sys.* The system structs like _iobuf are surely different.

I put versions and conditionals in when I created those that should support 64-bit.  All that should be required is possibly some fiddling with core.sys.posix.config and possibly core.stdc.config.  The headers obviously haven't been tested as thoroughly in a 64-bit environment though, so it's possible I screwed something up and we just don't know it yet.  The asm in core.atomic should support 64-bit as well.  I haven't take care of core.thread yet though.

Sean Kelly wrote:
>
> I put versions and conditionals in when I created those that should support 64-bit.  All that should be required is possibly some fiddling with core.sys.posix.config and possibly core.stdc.config.  The headers obviously haven't been tested as thoroughly in a 64-bit environment though, so it's possible I screwed something up and we just don't know it yet.  The asm in core.atomic should support 64-bit as well.  I haven't take care of core.thread yet though.
>
> 

Great!