www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - migrating to 64 bit

reply "Stephen Jones" <siwenjo gmail.com> writes:
I have just moved to Windows 8.1 64bit. I copied the dmd compiler 
and environment I was using on the 32 bit XP and hooked up the 
environmental variables to see what would happen. When I come to 
compile and run one of the Derelict3 programs it compiles and 
runs ok (mouse isn't doing what it should but haven't looked into 
why yet). The SDL2 dlls, including the ttf and image dlls are 
from the 32 bit environment and they seem to be working (window, 
text and images at least) on the 64 bit os. I am just trying to 
get my head around this.

I would assume, and please tell me if I am wrong as that is the 
point of the post, that any D code will compile on any dmd 
compiler irrespective of whether 32 or 64 bit. But I would have 
thought the object files compiled would be different, assuming 
that the compiler knowing its environment stipulates in the 
object files what the linker needs to do. Or am I wrong on this, 
and that the object files will be identical but the linker sc.ini 
defines will make the difference. If this last is true there 
would be no need for something like the gcc -m32 flag as that 
would be handled by the linker chosen. If it is not true then is 
there a dmd flag to demand that the exe be 32 bit compatible?

Also, what is the deal with using dlls from a 32bit system on a 
64bit os; is this just backwards compatibility?

Any help or helpful links appreciated.
Dec 14 2013
next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Sunday, 15 December 2013 at 00:10:20 UTC, Stephen Jones wrote:

 I have just moved to Windows 8.1 64bit. I copied the dmd 
 compiler and environment I was using on the 32 bit XP and 
 hooked up the environmental variables to see what would happen. 
 When I come to compile and run one of the Derelict3 programs it 
 compiles and runs ok (mouse isn't doing what it should but 
 haven't looked into why yet). The SDL2 dlls, including the ttf 
 and image dlls are from the 32 bit environment and they seem to 
 be working (window, text and images at least) on the 64 bit os. 
 I am just trying to get my head around this.

 I would assume, and please tell me if I am wrong as that is the 
 point of the post, that any D code will compile on any dmd 
 compiler irrespective of whether 32 or 64 bit. But I would have 
 thought the object files compiled would be different, assuming 
 that the compiler knowing its environment stipulates in the 
 object files what the linker needs to do. Or am I wrong on 
 this, and that the object files will be identical but the 
 linker sc.ini defines will make the difference. If this last is 
 true there would be no need for something like the gcc -m32 
 flag as that would be handled by the linker chosen. If it is 
 not true then is there a dmd flag to demand that the exe be 32 
 bit compatible?

 Also, what is the deal with using dlls from a 32bit system on a 
 64bit os; is this just backwards compatibility?

 Any help or helpful links appreciated.


Object files, dll's and executables file are built for a target. 
A target being Windows 32 bit x86 or Windows 64 bit x86 aka 
x86_64. Dmd at least to my belief shouldn't inject any special 
code dependent on the OS or platform. It will compile different 
to the target as all compilers should. (Excluding e.g. Java which 
compiles to an intermediate language).

If your own a 64bit machine I assume you will be wanting to also 
target 64bit? If so have you got the linker setup correctly? 
Because it requires Microsoft's linker provided in e.g. Visual 
c++. The free version should be fine.

Also Derelict3 is now obsolete. If you're a package you want is 
not yet converted into the new DerelictOrg[1] structure don't 
worry but if it has been you may want to convert over to it.

With regards to changing the target for e.g. dmd, currently it 
only supports changing to 64bit from 32bit. Not platform or 
architecture. Just utilising -m32 and -m64.

[1] https://github.com/DerelictOrg
Dec 14 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 15 December 2013 at 00:10:20 UTC, Stephen Jones wrote:

 Also, what is the deal with using dlls from a 32bit system on a 
 64bit os; is this just backwards compatibility?

 Any help or helpful links appreciated.


32bit code runs on 64bit platforms (you can thank AMD for that, 
as Linux does).
Dec 14 2013
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 15 Dec 2013 01:10:18 +0100
schrieb "Stephen Jones" <siwenjo gmail.com>:


 I would assume, and please tell me if I am wrong as that is the=20
 point of the post, that any D code will compile on any dmd=20
 compiler irrespective of whether 32 or 64 bit. But I would have=20
 thought the object files compiled would be different, assuming=20
 that the compiler knowing its environment stipulates in the=20
 object files what the linker needs to do. Or am I wrong on this,=20
 and that the object files will be identical but the linker sc.ini=20
 defines will make the difference. [=E2=80=A6]


The object files are different, possibly even the way
arguments are passed to functions. But most importantly
pointer variables, "size_t" (used for array lengths etc.) and
CPU registers have a different size. For that and other
reasons you could not mix 32-bit and 64-bit code by loading a
64-bit DLL into a 32-bit program or linking together different
format object files.
I don't know if the linker needs to be told -m32 or -m64 or if
it is smart enough to figure it out from the object files, but
would otherwise generate an error about incompatible object
file formats.


 Also, what is the deal with using dlls from a 32bit system on a=20
 64bit os; is this just backwards compatibility?


Basically yes.


 Any help or helpful links appreciated.


--=20
Marco
Dec 14 2013
prev sibling parent reply "Stephen Jones" <siwenjo gmail.com> writes:
Thanks for your answers but I wasn't quite clear about what I 
asking. Basically I am on a 64 bit os but I want to continue 
compiling for a 32 bit os. I don't want to reconfigure Derelict 
because I already have all the functionality I need from 
Derelict. Until dmd on Windows 64 bit is sorted out, including a 
clear procedure for setting up the linker I have no need or wish 
to compile for 64 bit. Especially since any d program that 
compiles on 32 bit will compile under 64 bit.

Is there a flag on dmd that forces it to assume it is creating 32 
bit object files? Or is this not possible?
Dec 16 2013
parent reply Mike Parker <aldacron gmail.com> writes:
On 12/17/2013 6:13 AM, Stephen Jones wrote:

 Thanks for your answers but I wasn't quite clear about what I asking.
 Basically I am on a 64 bit os but I want to continue compiling for a 32
 bit os. I don't want to reconfigure Derelict because I already have all
 the functionality I need from Derelict. Until dmd on Windows 64 bit is
 sorted out, including a clear procedure for setting up the linker I have
 no need or wish to compile for 64 bit. Especially since any d program
 that compiles on 32 bit will compile under 64 bit.



DMD *is* sorted out on Windows 64. To compile 32-bit, you do nothing 
special. To compile 64-bit programs, you set up the Visual Studio 
toolchain as described in the wiki[1] and pass the -m64 flag on the 
command line.


 Is there a flag on dmd that forces it to assume it is creating 32 bit
 object files? Or is this not possible?


Typeing 'dmd' with no args will show you all supported flags, including 
-m32 and -m64. The former generates 32-bit objects and the latter 64-bit 
objects. On Windows, 32-bit is the default so you do not need to do 
anything.

[1] 
http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible)
Dec 17 2013
parent "Stephen Jones" <siwenjo gmail.com> writes:
Thanks Mike. I had come to the same conclusion as the dmd 
environment I copied over from 32 bit XP is working exactly as it 
used to in 64bit windows 8. Just being paranoid under the weight 
of newness I guess; its out to make everything we do obsolete you 
know.
Dec 17 2013