Hi All :)
This topic is for all Visual C++ developers who love to put inline assembly (__asm) wherever it's appropriate (and wherever it isn't :D)
Recently I've tried to port my programs to x64. And I found a good article which explains how to incorporate x64 building capability into VS2003.
I've installed everything and successfully built a dialog based application. (What VS generates initially, without changes)
The big problem is that the x64 compiler does not support inline assembly... And I have a LOT of inline assembly and a lot of it is put into inline functions.
I don't know how, and don't want to mess around with *.asm files and custom builds. I'd like my code to stay as it is. (Of course nicely modified for the x64 platform)
I don't know how a code put into an ASM file can be inline. Many of my functions are small and the assembly code in them gets nicely built in.
If all that code should be called through a CALL instruction with all the stack operations, the performance goes to .. a very hot place full of devils :D (don't know if it's appropriate to say the word :D)
Now, I have a weird idea:
- To restore the inline assembly capability of Visual C++!
- How?
Here it is the method:
1) cl.exe is the x64 compiler (Yes it has the same name as the 32bit version). I rename it to cl64.exe and put my own console application under the name cl.exe. - what is does?
2) My cl.exe will be called by the IDE instead of the original (I strongly hope IDE does that seamlessly), and the IDE will pass to it the command line parameters together with the current CPP file. (the parameters will be passed to cl64.exe unchanged)
- Just to clarify: As far as I know the IDE calls cl.exe for every CPP file passing it as a command line together with the settings. (That you use to set up in the projects properties)
- In turn cl.exe sends feedback to the IDE trough an I/O stream and that's what you see in the output window. (Errors, warnings, which file is being compiled etc...) (Please correct me if I'm wrong about this).
3) Before my cl.exe passes the CPP file to the original cl64.exe for processing it will search for __asm blocks and:
4) It will save the assembly code;
5) It will make a copy of the CPP file where the __asm block is replaced with valid C code that does nothing but enough to full the optimizer not to ignore it.
- something like that:
int a = 0x01a2b3cd;
int b = 0x432adcbf;
int s = a + b + ... ;
One such line for every instruction. Those constants will be used later. They are essential.
6) My cl.exe makes valid ASM file with the assembly code it took from the __asm block and calls ml64.exe (standard part of the Platform SDK);
7) ml64.exe translates the code and produces an OBJ file;
8) My cl.exe calls cl64.exe with the copy of the original CPP file with the replaced code.
9) Cl64.exe compiles the file and produces another OBJ file;
10) My cl.exe opens the OBJ compiled by cl64.exe and finds the constants I've mentioned above in the binary code;
11) My cl.exe opens the OBJ made by ml64.exe and takes the binary code from there;
12) cl.exe substitutes the code block containing the constants with the binary code it took from the ml - OBJ file
After this the OBJ file is ready to be linked.
The problems I face right now are:
- I don't know the C++ OBJ file format. I need that for the searching of the constants. It's an ambiguous task. (I've found some info no that but it'll be best to discuss it here too)
- The x64 instruction format. I need to know what's the binary format of instruction like mov REG, constant.
- Also if you can get some other things that my be problematic please discuss them here :)
Thanks for your attention :)
If I get this done, I'll post an article here in CodeProject with the entire project included and test notes for how it works with VS2003 and VS2008, Plus explanation how to make VS2003 to build x64 applications.
P.S. PLEASE don't shoot me if this idea sounds too ridiculous for you! :D (if you thing that's impossible I'd be glad you to tell me why :) )
And sorry for the prolong TC!!
Submit an article or tip