MCL, a new machine code generator/library

[CloakerSmoker]

MCL, a new machine code generator/library for AHK. Written by @GeekDude and I.

https://github.com/G33kDude/MCL.ahk

No, the acronym doesn't stand for anything. I think it used to be "machine code library", but we decided to leave it ambiguous.

See the README for how to use it, and example projects. The Examples/ folder also has some simpler single file examples.

Supports both 32 and 64 bit AHK, although 32 bit support is a little tentative.

Requires a gcc based cross-compiler installed under PATH (named as gcc.exe/g++.exe or x86_64-w64-mingw32-gcc.exe/x86_64-w64-mingw32-g++.exe) to run the tests or compile any code.
I've had luck with mingw-w64 installed via Cygwin, and mingw-w64 installed via MYSYS2. I believe Geek has used TDM-GCC without anything breaking.

No dependencies required to run pre-compiled code (see Geek's cJson library for an example of running pre-compiled code).

Note: I'm not very good at checking the forums (or replying in a timely fashion), so feel free to join https://geekdude.io/discord and ping me in #mcl-mcode-lib if you'd like.

---

MCL has a few extra features compared to other machine code tools, the big ones being:

• Global variables
• "Exporting" functions/variables back to AHK
• Constant function pointers (ex: void(*)() pMyFn = MyFn; in global scope)
• Very large constants (ex: ... doubles, which gcc tends to promote to being a global constant, breaking code under other tools)

While that might sound like a very mismatched list, it means that MCL has just enough features that a solid subset of standard C code can be compiled under it, and run (more or less) fine.

The primary goal of MCL is to enable much more complex machine code functions/libraries without resorting to a dll. For example, Geek's cJson library, which is compiled under MCL, and makes use of global variables, "exporting" multiple functions, and floating point numbers.

MCL also supports a tiny subset of C++ (no STL, exceptions, or RTTI). For example, see the SpookyHash test, which uses a C++ implementation of the SpookyHash hashing algorithm.

MCL also adds the ability for code to "import" functions from dlls in the same way you can with DllCall. This feature doesn't replace dll files, and isn't the primary goal of the project. Just think of it as a cherry on top.

And a (low level) warning for this feature: There is a bug with mingw-w64 compilers which results in the stack being misaligned, which will cause a crash the next time a Windows API (or standard library) function is called from your C/C++. This bug can be tracked here.

For an example of "importing" functions, see my PDFGen example library, which uses a regular C library with a few headers changed around along with an incredible number of imported standard library functions.

---

How it works:
I'm still working on figuring out how to explain it. I'll reply to this post with a nice explanation eventually. If you have any specific questions, chances are I'll have an easier time answering them than explaining the whole thing, so please ask.

[robodesign]

This is stellar work.

My question is... I began coding c++ in Microsoft visual studio and compiling my own DLL to import in AHK. Would there be any benefits to using this library instead of msvc, aside from the already mentioned limitations ?

Best regards, Marius.

[Xeo786]

[*] "Importing" functions from DLLs

When we have dllcall already why using import function from MCL and again use dllcall for that function, is there benefit?

Can we load single dll file multiple times, for example one dll file have callback event and can register single function for that callback,
can we now register multiple callbacks by multiple import function from single dll?

I run MCL test on Win7 AHKU32, I suspect MCL is not supported, ok I get it, I need to run precompile code

[CloakerSmoker]

This is stellar work.

My question is... I began coding c++ in Microsoft visual studio and compiling my own DLL to import in AHK. Would there be any benefits to using this library instead of msvc, aside from the already mentioned limitations ?

Best regards, Marius.

The big thing I sort of forgot to mention is that once you've compiled your code, it doesn't require any external files, and runs as semi-regular mcode. So you can effectively write a "dll" and embed it into your script. Not to say that this wasn't already possible through adding your dll as a resource or whatever and dynamically loading it, but MCL is much more lightweight than a full on dll (and a little bit easier to interact with).

Of course, the import/export features are all optional.

As for using this instead of MSVC, that's up to you. I wouldn't expect much or a performance change, and the STL isn't supported at all, so this is much more suited for C projects.

I should clarify, the goal with MCL isn't to replace dll files (although it doesn't do a terrible job at it), it is to give an option halfway between traditional machine code, and a dll.

[CloakerSmoker]

[*] "Importing" functions from DLLs

When we have dllcall already why using import function from MCL and again use dllcall for that function, is there benefit?

Can we load single dll file multiple times, for example one dll file have callback event and can register single function for that callback,
can we now register multiple callbacks by multiple import function from single dll?

I run MCL test on Win7 AHKU32, I suspect MCL is not supported, ok I get it, I need to run precompile code

MCL doesn't replace dllcall, and directly dllcall-ing a function will always be faster than dllcall-ing an MCL exported function which calls the same function. The idea is that you can write a function which uses imported functions in the same way you would in a dll.

MCL doesn't work with dlls, but you could load the same code multiple times, and each "instance" would get a separate set of globals and all that. I don't really follow what you mean with that second question.

And with the tests failing, you'll want to read the error message. MCL couldn't find gcc.exe/g++.exe under PATH, so you need to manually specify your paths to them. Oh, I just noticed what the error message actually says. Will fix lol

[CloakerSmoker]

I've gone through and rewritten the post to be a little bit less dll-y. I confused myself into forgetting the QOL improvements and emphasizing the "fake dll" features.

[geek]

MCL is now available through the Ace bot in the AutoHotkey Discord!

If you want to get started with MCL but don't have a compatible compiler handy, you can use the bot to compile and test your code, using the "ahk" bot command:

Code: Select all

.ahk
#include <MCL>
MsgBox, % str := MCL.AHKFromC("int __main(int a, int b) { return a + b; }")
MsgBox, % DllCall(MCL.FromString(str), "Int", 1, "Int", 2, "CDecl Int")

The bot will execute the code, invoke the mingw compiler, and behave as you would generally expect MCL to, returning the text:

Code: Select all

V0.3|64;;__main:0;;32;HzBVSInliU0QiVUYi1UQi0UYAdBdw5CQkJCQkJCQkJCQkA==
3