No Inline-Assembly for x64 Builds?

  • Thread starter Thread starter Kerem Gümrükcü
  • Start date Start date
K

Kerem Gümrükcü

Hi,

am i right when i remember that Visual C++ 2008
has NO support for x64 Assembly Instructions. But
what if i want or even have to write some assembly
code and want to use it in my x64 Code? What then?
I have some C-Dlls that are 32Bit and they use some
32Bit Assembly Language. So if the __asm is no more
for x64, how can i include it anyway into my Dll's? Do
i have to work with external x64 Assembler and then link
object code to my VC++ Dll, or is there any other "Inline"
Method i can use?


Regards

Kerem
 
Kerem said:
Hi,

am i right when i remember that Visual C++ 2008
has NO support for x64 Assembly Instructions. But
what if i want or even have to write some assembly
code and want to use it in my x64 Code? What then?
I have some C-Dlls that are 32Bit and they use some
32Bit Assembly Language. So if the __asm is no more
for x64, how can i include it anyway into my Dll's? Do
i have to work with external x64 Assembler and then link
object code to my VC++ Dll, or is there any other "Inline"
Method i can use?

No, there's no other way. If you need x64 assembly, you have to author a
separate assembly-only module, assemble it with ml64 and link it into your
DLL/EXE.

-cd
 
OK, this looks like so much fun I have to post something. In my years as a
programmer, I usually wanted to write code in whatever language I wasn't
currently using at the moment. Whenever my environment was COBOL, I wanted
to program in assembly or BPL. When doing 'C', I wanted to do assembly and
vice versa. Maybe that was my personality and general antisocial nature
coming to the fore. However, with time the following are important
questions to ask:

1. Are you trying to build yourself a fortress where you are 'critical' to
the company?
2. Is the assembly impossible to write in 'C' or is it just 'easier'?
3. Any chance you could get hit by a bus and someone else need to maintain
the code? Maybe get a better offer somewhere else?
4. Are you lucky enough to not have to support the IA64?

Now to answers as I know them:

1. Write in assembly modules and place in a subdirectory containing just
that CPU's versions (such as x86, x64, ia64). Placing sources file in each
subdirectory can build each project independently. Put a dirs file in the
main source directory.
2. I have heard an __emit can be used, but it would be almost
unmaintainable.
3. It would be nice if the WDK had one example, but I understand why they
don't. I believe they still have to build some small pieces of the OS using
assembly even if just for the HAL, loader, or the boot files on the DVD.
 
Carl Daniel said:
No, there's no other way. If you need x64 assembly, you have to author a
separate assembly-only module, assemble it with ml64 and link it into your
DLL/EXE.
What about WDK: does it support inline assembly?

Boris
 
No the WDK does not support inline assember for x64.


--
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply




boris said:
boris said:
"Carl Daniel [VC++ MVP]"
Kerem Gümrükcü wrote:
Hi,

am i right when i remember that Visual C++ 2008
has NO support for x64 Assembly Instructions. But
what if i want or even have to write some assembly
code and want to use it in my x64 Code? What then?
I have some C-Dlls that are 32Bit and they use some
32Bit Assembly Language. So if the __asm is no more
for x64, how can i include it anyway into my Dll's? Do
i have to work with external x64 Assembler and then link
object code to my VC++ Dll, or is there any other "Inline"
Method i can use?

No, there's no other way. If you need x64 assembly, you have to author
a separate assembly-only module, assemble it with ml64 and link it into
your DLL/EXE.
What about WDK: does it support inline assembly?
I meant inline x64 assembly.
Does WDK support it?

Boris
 
Kerem Gümrükcü said:
Hi,

am i right when i remember that Visual C++ 2008
has NO support for x64 Assembly Instructions. But
what if i want or even have to write some assembly
code and want to use it in my x64 Code? What then?
I have some C-Dlls that are 32Bit and they use some
32Bit Assembly Language. So if the __asm is no more
for x64, how can i include it anyway into my Dll's? Do
i have to work with external x64 Assembler and then link
object code to my VC++ Dll, or is there any other "Inline"
Method i can use?


Regards

Kerem

Have you looked at the compiler-provided intrinsics? Using those you may not
need to have any native assembler.
As other have said, if you still absolutely need assembler, you have to
create assembler-only source files (.asm) and assemble/link them to your
driver. If nothing else, doing so will ease maintenance because you won't
have assembler sprinkled all over your C code.

Enio.
 
Hi,

thanks to all replies! The compiler intrinsics are the
prefered way for future usage,...

Regards

K.
 
Tim Roberts said:
The WDK includes exactly the same compilers as Visual C++.
I didn't realize that. Which version of Visual Studio does it correspond to?
VS2005?

Boris
 
Tim Roberts said:
The WDK includes exactly the same compilers as Visual C++.
I built some user-mode code with an old DDK (2003 SP1, I think). That DDK
compiler didn't use RTL assemblies from VS2005 - I think it just used
MSVCRT.DLL (and some related DLLs) - no assemblies at all. Also, ATL3.0
headers included were included with it, I think. I had impression that DDK
compiler was based on VC6 compiler. Did it change with WDK? Does it use
compilers from some recent release of VS?

Boris
 
boris said:
I built some user-mode code with an old DDK (2003 SP1, I think). That
DDK compiler didn't use RTL assemblies from VS2005 - I think it just
used MSVCRT.DLL (and some related DLLs) - no assemblies at all. Also,
ATL3.0 headers included were included with it, I think. I had
impression that DDK compiler was based on VC6 compiler. Did it change
with WDK? Does it use compilers from some recent release of VS?

There's no need for the new compiler to use the new CRT. It's the linker
that gets involved anyway, and it just uses whatever DLL corresponds to the
import library you pass it. By default it will use a particular CRT for
resolving externals, but you can override that with /NODEFAULTLIB

Now I'm under the impression that while the WDK ships the Visual C++
compilers, they are a different version, in between the versions shipped in
Visual Studio, due to the WDK team's own test and release cycle (WDK could
find bugs in the compiler and ship a version after the C++ team fixes them).
 
Ben Voigt said:
Now I'm under the impression that while the WDK ships the Visual C++
compilers, they are a different version, in between the versions shipped
in Visual Studio, due to the WDK team's own test and release cycle (WDK
could find bugs in the compiler and ship a version after the C++ team
fixes them).

Actually the WDK team ships the compiler that was used to build that
revision of the OS. And as Ben points out it not always the same as the
Visual C++ version, since the two groups are on differing schedules.
Whether it is new or older than the VC++ compiler is a matter of timing,
what is known is the OS will build successfully with it.


--
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
 
boris said:
I built some user-mode code with an old DDK (2003 SP1, I think). That DDK
compiler didn't use RTL assemblies from VS2005 - I think it just used
MSVCRT.DLL (and some related DLLs) - no assemblies at all. Also, ATL3.0
headers included were included with it, I think. I had impression that DDK
compiler was based on VC6 compiler. Did it change with WDK? Does it use
compilers from some recent release of VS?

The 3790 DDK (Windows 2003) has 13.10.2179.
My Visual Studio 2003 release is 13.10.3077.
The 3790.1830 DDK (Windows 2003 SP1) has 13.10.4035.

The 6000 WDK (Vista) has 14.00.50727.200.
The 6001.18001 WDK (Vista SP1) has 14.00.50727.278
My Visual Studio 2005 is 14.00.50727.762.
 
Back
Top