Few interesting things about all methods converted by il2cpp.exe
Notice a few interesting things about all methods converted by il2cpp.exe:
- These are not member functions in C++. All methods are free functions, where the first argument is the "this" pointer. For static functions in managed code, IL2CPP always passes a value of NULL for this first argument. By always declaring methods with the "this" pointer as the first argument, we simplify the method generation code in il2cpp.exe and we make invoking methods via other methods (like delegates) simpler for generated code.
- Every method has an additional argument of type MethodInfo* which includes the metadata about the method that is used for things like virtual method invocation. The Mono scripting backend uses platform-specific trampolines to pass this metadata. For IL2CPP, we’ve decided to avoid the use of trampolines to aid in portability.
- All methods are declared extern “C” so that il2cpp.exe can sometimes lie to the C++ compiler and treat all methods as if they had the same type.
- Types are named with a “_t” suffix. Methods are named with a “_m” suffix. Naming conflicts are resolved by appended an unique number to each name. These numbers will change if anything in the user script code changes, so you cannot depend on them from build to build.
The first two points imply that every method has at least two parameters, the "this" pointer and the MethodInfo
pointer. Do these extra parameters cause unnecessary overhead? While they clearly do add overhead,
we haven’t seen anything so far which suggests that those extra arguments cause performance problems.
Although it may seem that they would, profiling has shown that the difference in performance is not measurable.
We can jump to the definition of this ToString method using Ctags. It is in the Bulk_UnityEngine_0.cpp file.
The code in that method definition doesn’t look too much like the C# code in the Vector3::ToString() method.
However, if you use a tool like ILSpy to reflect the code for the Vector3::ToString() method, you’ll see that
the generated C++ code looks very similar to the IL code.
Why doesn’t il2cpp.exe generate a separate C++ file for the method definitions for each type, as it does for
the method declarations? This Bulk_UnityEngine_0.cpp file is pretty large, 20,481 lines actually! We found the
C++ compilers we were using had trouble with a large number of source files. Compiling four
thousand .cpp files took much longer than compiling the same source code in 80 .cpp files. So il2cpp.exe
batches the methods definitions for types into groups and generates one C++ file per group.
Now jump back to the method declarations header file and notice this line near the top of the file:
#include "codegen/il2cpp-codegen.h"
The il2cpp-codegen.h file contains the interface which generated code uses to access the libil2cpp runtime
services. We’ll discuss some ways that the runtime is used by generated code later.
