www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Assembly - 64-bit registers supported?

reply "deed" <none none.none> writes:
void main()
{
     asm
     {
         mov    RAX, 3;
     }
}

results in:
Error: undefined identifier 'RAX'

AX and EAX work.

Anything missing or isn't it yet implemented?
Jan 19 2013
next sibling parent reply "nazriel" <spam dzfl.pl> writes:
On Saturday, 19 January 2013 at 12:45:06 UTC, deed wrote:

 void main()
 {
     asm
     {
         mov    RAX, 3;
     }
 }

 results in:
 Error: undefined identifier 'RAX'

 AX and EAX work.

 Anything missing or isn't it yet implemented?


http://dpaste.dzfl.pl/0f79b5ba

Missing -m64 or something?
Jan 19 2013
parent reply "deed" <none none.none> writes:
 Missing -m64 or something?


Probably. I am on Windows using dmd 2.061 and optlink 8.00.12

dmd main.d -m64
Con't run 'bin\amd64\link.exe', check PATH

Setting LINKCMD64 to the same path as for LINKCMD in sc.ini:

dmd main.d -m64
OPTLINK : Warning 9: Unknown Option : MERGE
OPTLINK : Error 8: Illegal Filename
/NOLOGO prog   /MERGE:.minfobg=.minfodt /MERGE:.minfoen=.minfodt 
/MERGE:._deh_bg=._deh_eh /MERGE:._deh_en=._deh_eh

--- errorlevel 1


Do I need another linker?
Jan 19 2013
parent reply "nazriel" <spam dzfl.pl> writes:
On Saturday, 19 January 2013 at 13:12:47 UTC, deed wrote:

 Missing -m64 or something?


 Probably. I am on Windows using dmd 2.061 and optlink 8.00.12

 dmd main.d -m64
 Con't run 'bin\amd64\link.exe', check PATH

 Setting LINKCMD64 to the same path as for LINKCMD in sc.ini:

 dmd main.d -m64
 OPTLINK : Warning 9: Unknown Option : MERGE
 OPTLINK : Error 8: Illegal Filename
 /NOLOGO prog   /MERGE:.minfobg=.minfodt 
 /MERGE:.minfoen=.minfodt /MERGE:._deh_bg=._deh_eh 
 /MERGE:._deh_en=._deh_eh

 --- errorlevel 1


 Do I need another linker?


Ach, Windows.

Yeah, you need VS Linker when compiling for 64bits on Windows.
Can't help you more with this. I think there is somewhere 
step-by-step guide for 64bits+windows. (wiki.dlang.org maybe? not 
sure)
Jan 19 2013
parent reply "deed" <none none.none> writes:
 Do I need another linker?


 Ach, Windows.

 Yeah, you need VS Linker when compiling for 64bits on Windows.
 Can't help you more with this. I think there is somewhere 
 step-by-step guide for 64bits+windows. (wiki.dlang.org maybe? 
 not sure)


Thanks for your help!

The solution that worked out for me:
- compile with -m64
- convert objs to coffs (with external tool)
- link with microsoft visual studio linker. (Include 
phobos64.lib, libcmt.lib, oldnames.lib, shell32.lib and 
kernel32.lib)

I couldn't find the -m64 switch by running dmd or at 
http://dlang.org/dmd-windows.html. Is there another hidden switch 
to output coff-format directly?

Also, I didn't get it to work by configuring the sc.ini file and 
ended up with lots of unresolved symbols. Anyone having a correct 
sc.ini file they could post?
Jan 20 2013
parent reply Mike Wey <mike-wey example.com> writes:
On 01/20/2013 03:21 PM, deed wrote:

 Do I need another linker?


 Ach, Windows.

 Yeah, you need VS Linker when compiling for 64bits on Windows.
 Can't help you more with this. I think there is somewhere step-by-step
 guide for 64bits+windows. (wiki.dlang.org maybe? not sure)


 Thanks for your help!

 The solution that worked out for me:
 - compile with -m64
 - convert objs to coffs (with external tool)
 - link with microsoft visual studio linker. (Include phobos64.lib,
 libcmt.lib, oldnames.lib, shell32.lib and kernel32.lib)

 I couldn't find the -m64 switch by running dmd or at
 http://dlang.org/dmd-windows.html. Is there another hidden switch to
 output coff-format directly?


dmd should output coff when compiling with -m64


 Also, I didn't get it to work by configuring the sc.ini file and ended
 up with lots of unresolved symbols. Anyone having a correct sc.ini file
 they could post?


Mine looks like this:

[Version]
version=7.51 Build 020

[Environment]
LIB="% P%\..\lib"
DFLAGS="-I% P%\..\phobos" "-I% P%\..\druntime\import"
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\
WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v7.0\
LINKCMD=c:\dmd\bin\link.exe
LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe

VCINSTALLDIR and WindowsSdkDir may be different depending on the version 
of the installed windows SDK.

-- 
Mike Wey
Jan 20 2013
parent reply "deed" <none none.none> writes:
 dmd should output coff when compiling with -m64


You are right, no need for conversion. Coff is output.



 Anyone having a correct sc.ini file they could post?


 Mine looks like this:

 [Version]
 version=7.51 Build 020

 [Environment]
 LIB="% P%\..\lib"
 DFLAGS="-I% P%\..\phobos" "-I% P%\..\druntime\import"
 VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 
 9.0\VC\
 WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v7.0\
 LINKCMD=c:\dmd\bin\link.exe
 LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe

 VCINSTALLDIR and WindowsSdkDir may be different depending on 
 the version of the installed windows SDK.


Thanks!
Spaces in paths no problem and dirs should end with backslash..
This file works for me:

LIB="% P%\..\lib"
DFLAGS="-I% P%\..\..\src\phobos" 
"-I% P%\..\..\src\druntime\import"
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 
10.0\VC\
WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v7.1\
LINKCMD=c:\dmd\bin\link.exe
LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe
Jan 20 2013
parent reply "dale" <ddd ddd.com> writes:
I am following these helpful suggestions, but still having 
trouble linking properly. I have Visual Studio 10 and its 64-bit 
extension installed, and I believe the amd64\link.exe is getting 
called, but I must have something configured incorrectly, because 
it does not appear to find all of the libraries correctly.

C:\prj\D>dmd -m64 hello64B.d

C:\d\dmd2\windows\bin\..\lib\shell32.lib : warning LNK4003: 
invalid library format; library ignored
C:\d\dmd2\windows\bin\..\lib\kernel32.lib : warning LNK4003: 
invalid library format; library ignored
phobos64.lib(dmain2_4a8_47b.obj) : error LNK2019: unresolved 
external symbol GetCommandLineW referenced in function _d_run_main
phobos64.lib(dmain2_4a8_47b.obj) : error LNK2019: unresolved 
external symbol CommandLineToArgvW referenced in function 
_d_run_main
...

And zillions more "unresolved externals" follow.

Why is it trying to include shell32.lib and kernel32.lib for a 
64-bit app? Is that a problem?

Any hints as to what I'm missing?

Thanks,
dale
Jan 23 2013
parent Mike Wey <mike-wey example.com> writes:
On 01/24/2013 01:08 AM, dale wrote:

 I am following these helpful suggestions, but still having trouble
 linking properly. I have Visual Studio 10 and its 64-bit extension
 installed, and I believe the amd64\link.exe is getting called, but I
 must have something configured incorrectly, because it does not appear
 to find all of the libraries correctly.

 C:\prj\D>dmd -m64 hello64B.d

 C:\d\dmd2\windows\bin\..\lib\shell32.lib : warning LNK4003: invalid
 library format; library ignored
 C:\d\dmd2\windows\bin\..\lib\kernel32.lib : warning LNK4003: invalid
 library format; library ignored
 phobos64.lib(dmain2_4a8_47b.obj) : error LNK2019: unresolved external
 symbol GetCommandLineW referenced in function _d_run_main
 phobos64.lib(dmain2_4a8_47b.obj) : error LNK2019: unresolved external
 symbol CommandLineToArgvW referenced in function _d_run_main
 ...

 And zillions more "unresolved externals" follow.

 Why is it trying to include shell32.lib and kernel32.lib for a 64-bit
 app? Is that a problem?

 Any hints as to what I'm missing?

 Thanks,
 dale


I think this has come up before, and it has something to do with some 
environment variables set in sc.ini and the MS linker picking up the 
libs supplied be dmd for win32 because of it.

-- 
Mike Wey
Jan 24 2013
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Saturday, 19 January 2013 at 12:45:06 UTC, deed wrote:

 void main()
 {
     asm
     {
         mov    RAX, 3;
     }
 }

 results in:
 Error: undefined identifier 'RAX'

 AX and EAX work.

 Anything missing or isn't it yet implemented?


  Hmm. I know there's a one byte 'escape code' that for x86 allows 
you to force it to a higher/lower level, perhaps that was just 
the 16/32 bit code and won't work for 64bit (different escape 
code?). I think it was 0x66, so you might get away 'db' 
prepending that, but I wouldn't rely on it. Sides there's lots of 
little intricacies of the instruction set; like you could have a 
one byte assignment to any register; That's assuming they aren't 
taking them away in the 64bit versions of x86.

  So...
   asm
   {
      db 66h;
      mov    EAX, 3;   //may work, likely 1 byte assignment
      db 66h;
      mov    EAX, 300; //4 byte assignment from 32bit register
      //4 byte padding needed for 64bit.
      //Little endian would allow this to work
      db 0,0,0,0;
   }

  But that's mostly informational, refer to the technical manual 
from Intel  before attempting.

  Hmmm I wonder, with the 64 bit systems, do they still use the 
segment registers (CS, DS, SS)? I can see it being used for 
telling apart virtual memory and code/data, but not for hardly 
anything else; Plus it's original use has long since been 
unneeded.
Jan 19 2013
prev sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
On 19-01-2013 13:45, deed wrote:

 void main()
 {
      asm
      {
          mov    RAX, 3;
      }
 }

 results in:
 Error: undefined identifier 'RAX'

 AX and EAX work.

 Anything missing or isn't it yet implemented?


You just need to pass -m64. The full x86-64 instruction set and all of 
its registers are supported.

-- 
Alex Rønne Petersen
alex alexrp.com / alex lycus.org
http://lycus.org
Jan 20 2013