Inline assembler comment from newsgroup

[Magnum]

This is from an assembly newsgroup and I asked about the statement.

Only part makes any sense to me.

Are they saying that M.S. no longer makes ml.exe and link.exe for 64 bit versions?

Microsoft has eliminated the inline assembler in it's 64-bit versions of
Visual Studio. I was getting ready production code based upon
C/C++/inline-assembly in 32-bit land, but now I will not deploy because
of the removal of the inline assembler (and the imminent ubiquitousness
of 64-bit computing in desktop and server environments). I feel
"flabergasted" or something. Rug pulled out from under me! Your (any/all
of you that I have yet to meet and are surely gurus of the technology)
thoughts?

[donkey]

Visual Studio does not use MASM for inline assembly, it is handled by the compiler directly so ml.exe is obviously not supported. It is true that inline assembly (at least in VS2010) does not support either the Itanium or x64 processors but ml64 does support these processors and you can always build the assembly portions separately and link them to your C/C++ program. The other option is to use the intrinsics which are available if you don't wish to build the modules separately. MS explains your options here:

MASM for x64 (ml64.exe)

[BogdanOntanu]

The idea is that only "inline" ASM is no longer supported in VS2010. This means that you can not mix standard C/C++ code with ASM statements in the same C/C++ file anymore.

However you can still use ml.exe (32bits or 64bits) to generate .OBJ files from .ASM files an link them together with other .OBJ files generated from C/C++ files in order to obtain an final executable that contains a mixture of C/C++ and ASM functions.

For your example this is what they meant:

Code Select Expand


int main (argc, *argv[])
{
  printf ("\n This used to work in 32 bits but does not work in 64 bits anymore.);
  __asm int3;

  return 0;
}


What you can still do is to put all of your ASM functions in an sepparated .ASM file and compile them to an OBJ or maybe an DLL with "optimized" functions.

This is the recommended method anyway.

[Magnum]

Thanks you gentlemen for the good info.

Way back when I was programming in C++ and C, I wondered why things like "getting the date" showed up in the .exe were there when there was no use for it. (At least that I could see.)

Maybe the current compilers are better.

[Vortex]

Hi Magnum,

You could check another development tool set, PellesC 64-bit to see if it supports inline assembler.

[hutch--]

It has been the case for a while that inlining asm code in a C compiler is problematic. The optimiser in the C Compiler uses registers according to RISC theory, not the Intel ABI so when you use inline asm the compiler must make an exception to how it works internally to provide registers for the inlined asm function and if the function is very small the sheer overhead just to call it often negates the advantages of using the inline code.

It is not a dis-similar problem linking assembler modules to a C program in that your EXTERN call still must be set up in terms of registers but the solution is to write a large enough section in asm so that the setup and call overhead is not a factor.

Code Select Expand


yourproc proc var:DWORD
    mov eax, var
    add eax, 1
    ret
yourproc endp


This would be a disaster as the setup and call overhead would be far larger than any gain you may get from a small instruction count where if you set up a search algo or sorting algo or anything else that is a complex time consuming operation, you will see speed gains if the code is fast enough.

[frktons]

Hi Magnum,

You could check another development tool set, PellesC 64-bit to see if it supports inline assembler.

It doesn't.  :wink

[Magnum]

Hi Magnum,

You could check another development tool set, PellesC 64-bit to see if it supports inline assembler.

Thanks, my question was just for information purposes.

Side Question

I was talking to webpage designer about all kinds of computer topics.

He was saying that, and here is where things got real cloudy for me.  :dazzled:

He said that there is quite a bit of hardware that either
doesn't have both 32 and 64 bit drivers available and will refuse to load and gives the B.S.O.D. or something similar?

I think he also said that some of the hardware did not have certified hardware drivers too.

Is that true or an exaggeration?