Yesterday I learned that inline assembly (with the __asm keyword) is not supported under Microsoft Visual C++ when compiling for AMD64 and Itanium targets.
Is that correct? And if so, does anyone know why they would not support inline assembly for those targets? It seems like a rather big feature to just drop...
Correct, it still isn't supported in VS 2010 Beta 1. My guess is that inline assembly is just too difficult to implement: the way Microsoft implemented it, it integrates with the surrounding C code so that data can flow in and out of the C code, and appropriate glue code is automatically injected. For that, the C compiler actually needs to understand the assembler code; they just haven't implemented that for AMD64 and Itanium.
It seems like a rather big feature to just drop...
It's quite easy to call a function written with an assembler, as long as you follow C conventions. This tutorial explains how.
Related
I have some C code I would like to optimize. It turns out the Intel C Compiler (ICC) does a much better job at this than GCC but I don't have a copy of that compiler and it is very expensive. However, I can compile it using ICC and get the assembly online at godbolt.org.
If I copy and paste this assembly into a text file, how can I then convert it into a functioning executable?
You will need to begin by making sure that the runtime environment for which godbolt.org compiles is similar enough to your runtime environment, (good luck with that,) because for example you may be using windows, and godbolt.org may be using linux, (or the other way around,) so when you bring the assembly to your system you might be able to convert it to object code, but it will still not link and it will not run.
Then you will need to find an assembler for your platform which is compatible with the syntax of assembly produced by the intel C compiler of godbolt.org so as to produce object files from the assembly files. (Good luck with that.)
Then you will need to find any and all runtime libraries (redistributables) required by code produced by the intel C compiler. (Good luck with that.)
Finally you will need to obtain a linker to link your resulting object files with the runtime libraries to produce an executable. (Good luck with that.)
Sometimes we need honest answers to our questions just so that we can realize how impossible our ideas are.
My question is actually more general than the title:
At what point does the architecture matter when writing code that will eventually be compiled to LLVM intermediary code, and then from there to the machine language?
Let's say I'm writing Rust (which uses LLVM as a backend). Am I automatically capable of compiling my Rust code to every architecture that LLVM can target (assuming there's an OS on that machine that can run it)?
Or could it be that the Rust standard library hasn't been made "ARM compatible" yet, so I couldn't compile to ARM even if the LLVM targets it?
What if I don't use any of the standard library, my entire program is just a program that returns right away? Could it be the case that even without any libraries, Rust (or what have you) can't compile to ARM (or what have you) even if the LLVM targets it?
If all the above examples compile just fine, what do I have to do to get my code to break on one architecture not compile to a certain architecture?
Bonus question of the same variety:
Let's say the standard library makes use of OS system calls (which is surely does). Do you have to care about architecture when making system calls? Or does the OS (Linux, for example) abstract away architecture as well?
Thanks.
TL;DR
From my understanding you can compile to any target LLVM supports (there may still be a few caveats here with frontends using inline assembler or module level inline assembly), however, you are not guaranteed it will actually execute correctly. The frontend is responsible for doing the work to be portable across the platforms the author supports.
Note also that as a frontend developer you are responsible for providing the data layout and target triple.
see also:
llvm-bitcode-cross-platform
llvm
FAQ
Implementing Portable
sizeof
Cross Compile with Clang
Your Questions:
Let's say I'm writing Rust (which uses LLVM as a backend). Am I
automatically capable of compiling my Rust code to every architecture
that LLVM can target (assuming there's an OS on that machine that can
run it)?
This is dependent on the authors of the Rust frontend.
Or could it be that the Rust standard library hasn't been made "ARM
compatible" yet, so I couldn't compile to ARM even if the LLVM targets
it?
I'm pretty sure LLVM would be able to emit the instructions, but it may not be correct in terms of addressing.
I have not used the inline assembler facilities mentioned above myself, but I assume if it allows platform specific assembly then this would break platform agnostic compilation as well.
What if I don't use any of the standard library, my entire program is
just a program that returns right away? Could it be the case that even
without any libraries, Rust (or what have you) can't compile to ARM
(or what have you) even if the LLVM targets it?
This again depends on what the Rust frontend emits. There may be some boilerplate setup logic it emits even before it emits instructions for your logic.
I'm writing my own language in LLVM that does this in the case of a special function called "main". I am targeting the C ABI so it will wrap this main with a proper C style main and invoke it with a stricter set of parameters.
If all the above examples compile just fine, what do I have to do to
get my code to break on one architecture not compile to a certain
architecture?
Consider C/C++ with Clang as mentioned in the llvm FAQ. Clang is a frontend, probably the most popular, for LLVM and the users writing C/C++ are responsible for #include-ing the appropriate platform specific functionality.
Some languages may be designed more platform independent and the frontend could then handle the work for you.
Let's say the standard library makes use of OS system calls (which is
surely does). Do you have to care about architecture when making
system calls? Or does the OS (Linux, for example) abstract away
architecture as well?
I'm assuming you are talking about the case where the frontend targets the C standard library in which case LLVM has standard C library intrinsics which could be used by the frontend. This is not the only way, however, as you can use the call instruction to invoke C functions directly if targeting the C ABI as in the Kaleidoscope example.
In the end the standard library can be a portability issue and must be addressed by the frontend developers.
I am currently following a course at my University in which, at this stage, we learn about the assembler code behind certain C/C++ constructs.
The workflow usually goes like this: the lab assistant briefly speaks about a topic, we figure out the quirks and then solve some totally random problem using inline assembly.
(For example: He briefly talks about how struct (members) are stored in memory, we figure out the pattern and then we write the solution using inline assembly to a simple problem in which we use a struct.)
The lab assistant (as well as the rest of the group) is using the Visual C++ compiler and debugger (for disassembly) for his demonstrations however I cannot use it due to ethical reasons and thus I opted for g++ and gdb.
What I find awkward about g++'s inline assembly compared to Visual C++ is the fact that:
If I want to write a 'block' of inline assembly I have two options: Have a single asm("..") construct in which each instruction is preceded by a \n\t (leads to a lot of clutter). Or have each instruction in its own asm("..") block (leads to a lot of typing).
If I want to reference a local variable in the inline assembly I have to either use the extended syntax or reference it by using offsets to esp/ebp.
In respect to the two issues above I prefer the Visual C++'s inline assembly style in which in order to write an asm block all I have to do is __asm { .. } and write each instruction on a new line and in order to reference a variable I just have to write its name.
Throughout my searches I have discovered that Apple's g++ supports the same syntax as Visual C++ with a switch (-fasm-blocks) however this does not seem to be the case for GNU g++.
In the hopes that I might have missed something I am asking here if it is possible to compile Visual C++ like inline assembly blocks under GNU g++.
The syntax you are referring to is not Microsoft specific. As you have found, Apple had it too (although Apple gave up on GCC and switched to Clang). AFAIK, Metrowerks supports the same syntax. GCC does not support it (probably because GCC guys believe that GCC is so good that nobody needs to write assembly anymore :-)). However, there is no need to type \n\t all the time, you can replace it with ;. For example:
void foo()
{
asm("xor %eax,%eax;"
"rep; nop;"
"nop;"
"sfence;"
"nop;");
}
Hope it helps. Good Luck!
Does anyone know if LLVM binary compatibility is planned for visual studio combiled .obj and static .lib files?
Right now I can only link LLVM made .obj files with dynamic libs that loads a DLL at runtime (compiled from visual studio).
While there probably is very small chances that binary compatibility will happen between the two compilers, does anybody know why it is so difficult achieving this between compilers for one platform?
As Neil already said, the compatibility includes stuff like calling convention, name mangling, etc. Though these two are the smallest possible problems. LLVM already knows about all windows-specific calling conventions (stdcall, fastcall, thiscall), this is why you can call stuff from .dll's.
If we speak about C++ code then the main problem is C++ ABI: vtable layout, rtti implementation, etc. clang follows Itanium C++ ABI (which gcc use, for example, among others), VCPP - doesn't and all these are undocumented, unfortunately. There is some work going in clang in this direction, so stuff might start to work apparently. Note that most probably some parts will never be covered, e.g. seh-based exception handling on win32, because it's patented.
Linking with pure C code worked for ages, so, you might workaround these C++ ABI-related issues via C stubs / wrappers.
Apart from anything else, such as calling conventions, register usage etc, for C++ code to binary compatible the two compilers must use the same name-mangling scheme. These schemes are proprietory (so MS does not release the details if its scheme) and are in any case in a constant state of flux.
Is it possible to create, edit, link, compile (is compile the word?) etc. assembly code in MSVC++?
Also, if it's not possible, how can I create an .exe out of plain text, ie: convert the text into whatever format is required to use assembly code, then turn the assembly code into an .exe. (I'd say compile, but I don't think that is the correct word here).
And finally, what are some good places to begin learning assembly code? Written in a way that someone who has little experience can use.
I know some of these questions are probably very stupid, but I have absolutely no experience in assembly code and am not exactly sure where to start.
On x86, yes. You can use the __asm keyword to put assembly inline in your standard source files, and use the normal MS compile/link tools to compile everything together.
On x64 (or x86), you may need to use the ML and ML64 command line compilers for assembly.
Visual Studio provides the __asm keyword for compiling inline assembly in c and c++. There is also a good discussion here on the use of inline assembly. However if you are just talking about compiling assembly on it's own I'm not sure if Visual C++ is the correct tool however I'm pretty sure visual studio ships with the MASM assembler.
In short, yes.
According to Wikipedia, MASM has been shipped with all versions of Visual C later than VC6, and is also available in the Windows Driver Developer Kit. Versions supporting 16-bit real and protected modes, 32-bit, and 64-bit are all supported.
You can use the __asm keyword to write inline assembly.
pcasm-book(pdf) is a good tutorial to start assembly code programming.
Yes, sort of.
C:\Program Files\Microsoft Visual Studio 9.0\vc\bin>ml
Microsoft (R) Macro Assembler Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
usage: ML [ options ] filelist [ /link linkoptions]
Run "ML /help" or "ML /?" for more info
You'd use the macro assembler. I don't know if Visual Studio will automatically "do the right thing" with .asm files, though, but you can certainly edit them with it and assemble them with ml.exe.
A good place to start learning assembly language might actually be by learning about reverse engineering.
Look for information on the C++ 'asm' keyword. It may be compiler specific, but I know VC++ supports it.