Jump to content
scintilla4evr

CompileIt - an experimental AutoIt-to-machine code compiler

Recommended Posts

Skysnake

Hi. 

I have Code Blocks installed and nothing much to do with it... :(

Welcome to Code::Blocks 13.12!
Code::Blocks is a full-featured IDE (Integrated Development Environment) aiming to make the individual developer (and the development team) work in a nice programming environment offering everything he/they would ever need from a program of that kind.
Its pluggable architecture allows you, the developer, to add any kind of functionality to the core program, through the use of plugins...

I get this error when compiling the Hello, World!.c ...

#include "#1 - Hello, World!.h"

// Globals

// Script entry
int main() {

au3_consolewrite(string_variant(L"Hello, World from machine code AutoIt!"));


return 0;
}
______________________________
Build log:

mingw32-gcc.exe   -c "C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.c" -o "C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.o"
mingw32-g++.exe  -o "C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.exe" "C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.o"   
C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.o:#1 - Hello, World!.c:(.text+0x16): undefined reference to `string_variant'
C:\AutoIt\CompileIt\test\__build\#1 - Hello, World!.o:#1 - Hello, World!.c:(.text+0x22): undefined reference to `au3_consolewrite'
collect2.exe: error: ld returned 1 exit status
Process terminated with status 1 (0 minute(s), 0 second(s))
2 error(s), 0 warning(s) (0 minute(s), 0 second(s))

Perhaps the ChakraCore.dll is in the wrong place? 

Skysnake

Edited by Skysnake

Skysnake

Why is the snake in the sky?

Share this post


Link to post
Share on other sites
scintilla4evr
43 minutes ago, Skysnake said:

Perhaps the ChakraCore.dll is in the wrong place? 

Okay, so the ChakraCore.dll has nothing to do with the actual C code compilation process - it's used to execute the parser used to convert AutoIt code to C. You got the resulting C code, so ChakraCore had done its job.

And with the build, the reason why it doesn't work is the fact that the C files from CompileIt's include/ directory had not been compiled with the input source code.

So, I would recommend using the CompileIt.exe for compiling those scripts.

But if you find Code::Blocks more comfortable, just add the files from CompileIt's include/ directory to your project. The build should continue just fine.

Edited by scintilla4evr

Share this post


Link to post
Share on other sites
Skysnake

:)

Got this far

-------------- Build: Debug in CompileItExample (compiler: GNU GCC Compiler)---------------

mingw32-gcc.exe -Wall -g  -c "C:\AutoIt\CompileIt\project\#1 - Hello, World!.c" -o "obj\Debug\#1 - Hello, World!.o"
mingw32-gcc.exe -Wall -g  -c C:\AutoIt\CompileIt\project\AutoItFuncs.c -o obj\Debug\AutoItFuncs.o
C:\AutoIt\CompileIt\project\AutoItFuncs.c: In function 'au3_stringlen':
C:\AutoIt\CompileIt\project\AutoItFuncs.c:32:5: warning: passing argument 1 of 'wcslen' from incompatible pointer type [enabled by default]
     return int_variant(wcslen(vt.data_ptr));
     ^
In file included from C:\AutoIt\CompileIt\project\AutoItFuncs.c:4:0:
c:\program files (x86)\codeblocks\mingw\include\string.h:133:40: note: expected 'const wchar_t *' but argument is of type 'int *'
 _CRTIMP size_t __cdecl __MINGW_NOTHROW wcslen (const wchar_t*);
                                        ^
C:\AutoIt\CompileIt\project\AutoItFuncs.c: In function 'au3_stringreverse':
C:\AutoIt\CompileIt\project\AutoItFuncs.c:38:5: warning: passing argument 1 of 'wcsrev' from incompatible pointer type [enabled by default]
     return string_variant(wcsrev(vt.data_ptr));
     ^
In file included from C:\AutoIt\CompileIt\project\AutoItFuncs.c:4:0:
c:\program files (x86)\codeblocks\mingw\include\string.h:185:42: note: expected 'wchar_t *' but argument is of type 'int *'
 _CRTIMP wchar_t* __cdecl __MINGW_NOTHROW wcsrev (wchar_t*);
                                          ^
C:\AutoIt\CompileIt\project\AutoItFuncs.c: In function 'au3_stringcompare':
C:\AutoIt\CompileIt\project\AutoItFuncs.c:44:5: warning: passing argument 1 of 'wcscmpi' from incompatible pointer type [enabled by default]
     return int_variant(wcscmpi(vt1.data_ptr, vt2.data_ptr));
     ^
In file included from C:\AutoIt\CompileIt\project\AutoItFuncs.c:4:0:
c:\program files (x86)\codeblocks\mingw\include\string.h:173:29: note: expected 'const wchar_t *' but argument is of type 'int *'
 int __cdecl __MINGW_NOTHROW wcscmpi (const wchar_t * __ws1, const wchar_t * __ws2);
                             ^
C:\AutoIt\CompileIt\project\AutoItFuncs.c:44:5: warning: passing argument 2 of 'wcscmpi' from incompatible pointer type [enabled by default]
     return int_variant(wcscmpi(vt1.data_ptr, vt2.data_ptr));
     ^
In file included from C:\AutoIt\CompileIt\project\AutoItFuncs.c:4:0:
c:\program files (x86)\codeblocks\mingw\include\string.h:173:29: note: expected 'const wchar_t *' but argument is of type 'int *'
 int __cdecl __MINGW_NOTHROW wcscmpi (const wchar_t * __ws1, const wchar_t * __ws2);
                             ^
mingw32-gcc.exe -Wall -g  -c C:\AutoIt\CompileIt\project\CompileIt.c -o obj\Debug\CompileIt.o
C:\AutoIt\CompileIt\project\CompileIt.c: In function 'variant_getstring':
C:\AutoIt\CompileIt\project\CompileIt.c:86:9: warning: return makes pointer from integer without a cast [enabled by default]
         return *((wchar_t*)vt.data_ptr);
         ^
mingw32-g++.exe  -o bin\Debug\CompileItExample.exe "obj\Debug\#1 - Hello, World!.o" obj\Debug\AutoItFuncs.o obj\Debug\CompileIt.o   
Output file is bin\Debug\CompileItExample.exe with size 53.05 KB
Process terminated with status 0 (0 minute(s), 0 second(s))
0 error(s), 5 warning(s) (0 minute(s), 0 second(s))

My cbp project file

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_project_file>
	<FileVersion major="1" minor="6" />
	<Project>
		<Option title="CompileItExample" />
		<Option pch_mode="2" />
		<Option compiler="gcc" />
		<Build>
			<Target title="Debug">
				<Option output="bin/Debug/CompileItExample" prefix_auto="1" extension_auto="1" />
				<Option object_output="obj/Debug/" />
				<Option type="1" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-g" />
				</Compiler>
			</Target>
			<Target title="Release">
				<Option output="bin/Release/CompileItExample" prefix_auto="1" extension_auto="1" />
				<Option object_output="obj/Release/" />
				<Option type="1" />
				<Option compiler="gcc" />
				<Compiler>
					<Add option="-O2" />
				</Compiler>
				<Linker>
					<Add option="-s" />
				</Linker>
			</Target>
		</Build>
		<Compiler>
			<Add option="-Wall" />
		</Compiler>
		<Extensions>
			<code_completion />
			<envvars />
			<debugger />
			<lib_finder disable_auto="1" />
		</Extensions>
	</Project>
</CodeBlocks_project_file>

which results in

compileIt.png

:):):):):):):):):):):):):):):):):):):):):):):)

You rock man!

Skysnake

 

Edited by Skysnake
  • Like 2

Skysnake

Why is the snake in the sky?

Share this post


Link to post
Share on other sites
Deye

Well done,
So this potentially will have faster execution times to what it can support so far ...
Was looking to see something like this already done !

Thanks for sharing

  • Like 1

Share this post


Link to post
Share on other sites
scintilla4evr
21 minutes ago, Deye said:

So this potentially will have faster execution times to what it can support so far

Well, according to some simple tests I performed while developing new features, CompileIt reached about 2x faster execution. But when I got to loops with a lot of iterations, it sometimes executed slower than AutoIt, because the whole thing is not optimized in any way.

But then again, let us wait and maybe things will change :)

  • Like 1

Share this post


Link to post
Share on other sites
Skysnake

Development suggestion? My problem is this: the compiled EXE is so fast, its almost impossible to see it processing...  Suggested solution: include a standard "filewrite" option to write to disk during execution.  Much like AutoIt's FileWrite or FileWriteLog functions.  Then one can trace the EXE activity.

Perhaps there is a different/better solution?

:)


 

Edited by Skysnake

Skysnake

Why is the snake in the sky?

Share this post


Link to post
Share on other sites
scintilla4evr
1 hour ago, Skysnake said:

Development suggestion? My problem is this: the compiled EXE is so fast, its almost impossible to see it processing...  Suggested solution: include a standard "filewrite" option to write to disk during execution.  Much like AutoIt's FileWrite or FileWriteLog functions.  Then one can trace the EXE activity.

Perhaps there is a different/better solution?

:)


 

File manipulation/creation functions are on the to-do list, but first I want to make sure that Strings are more functional (for example, adding the & operator).

Share this post


Link to post
Share on other sites
Skysnake

Let me know what I can test. :)

 


Skysnake

Why is the snake in the sky?

Share this post


Link to post
Share on other sites
TheDcoder

A huge undertaking, good luck with the project @scintilla4evr!


AutoIt.4.Life Clubrooms - Life is like a Donut (secret key)

Spoiler

My contributions to the AutoIt Community

Some messages & Apologizes:

If I hurt you, Please accept my apologies, I never (regardless of the situation) mean to hurt anybody!!!

Also, I am very busy with my project so I will appear in the last row of the online list, if you want to contact me: Email@TheDcoder.xyz

Or you can have a nice chat with me in freenode, I use the same nick on freenode too!

3fHNZJ.gif

PLEASE JOIN ##AutoIt AND HELP THE IRC AUTOIT COMMUNITY!

Share this post


Link to post
Share on other sites
Biatu

I am extremely interested in this project, can you setup a github?


What is what? What is what.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • Earthshine
      By Earthshine
      So, I made this console app--using TreeWalkers of course to walk the UI Tree-- that starts at the root and looks for enabled, active controls--and in piping that to a file, I got this (edited, lots of controls in that list), above. LOL, so, those commands that are stored in memory are control elements! Sweet. this UIAutomation stuff is awesome. @junkew got me into this, blame his IUIAutomation kit. So there is this OLD vb OCX that is super ornery, but his kit can manipulate it, even if it is just SendKeys, So I must build a C# wrapper of my own... LOL this stuff is so cool. I have tried TestStack.White and MANY other wrappers, they seriously suck, no support either.
      I used canned Microsoft example code too for the most part. This is an extreme for me though, our modern stuff I can test easily enough, but I want my own kit to use to discover and poke around with. I like to use the IUIAutomation tool as a sanity check too, it's very useful.
       
    • scintilla4evr
      By scintilla4evr
      This is an experimental AutoIt-to-machine code compiler, written in AutoIt, JavaScript and C.
      Make sure you have GCC installed and configured within CompileIt before using.
    • Ward
      By Ward
      I have wrote a lot of binary code library for AutoIt before. I also discover many ways to generate binary code for AutoIt in the past. However, all of them have limitation or need some extra effort.   Recently, I think I found the best and easiest way to generate the binary code. So I wrote this UDF, may be my last one about binary code.   The Features: Both AutoIt x86 and x64 version are supported. Windows API and static variables can be use (code relocation supported). Decompression at run-time with smallest footprint LZMA decoder. Allocated memory blocks are released automatically. Most C source code works without modification. Two step or one step script generation, very easy to use. How It Works:
      The C source code must be compiled by MinGW GCC with "-S -masm=intel" option. Output is GAS syntax assembly file. BinaryCall Tool is able to convert the GAS syntax assembly file (*.s) to FASM syntax (*.asm). During the conversion, global symbols will be stored as "Symbol Jump Table" at the head of the file. The output file should be able to be assembled to binary file under command line by FASM.EXE. This syntax conversion is step 1. The step 2 is to assemble the file. BinaryCall Tool will use the embedded FASM to assemble every file twice to generate the relocation table. "BinaryCall.inc" will be included automatically before assembling to detect the Windows API and generate the "API Jump table". All the results will be compressed and converted to AutoIt script output. There are two major functions in the output script. _BinaryCall_Create() function allocates memorys, decompress the binary, relocates the address in memory, and fills the "API Jump Table". _BinaryCall_SymbolList() converts the "Symbol Jump Table" to memory addresses, and then store them as pointers in a DllStruct variable. Finally, we can use DllCallAddress() to call the memory address stored in the DllStruct. Step by Step Tutorial:
      Write C source code:#include <windows.h> void main() { MessageBox(0, "Hello", "Welcome Message", 1); } Use GCC MinGW 32/64 to compile the source code:
      gcc -S -masm=intel -m32 MessageBox.c Use BinaryCall Tool "GAS2AU3 Converter", select "MessageBox.s":
      If Not @AutoItX64 Then Local $Code = '...' Local $Reloc = '...' Local $Symbol[] = ["main"] Local $CodeBase = _BinaryCall_Create($Code, $Reloc) If @Error Then Exit Local $SymbolList = _BinaryCall_SymbolList($CodeBase, $Symbol) If @Error Then Exit EndIf Paste the output script, call the main() in AutoIt:
      #Include "BinaryCall.au3" ; Paste output here DllCallAddress("none:cdecl", DllStructGetData($SymbolList, "main")) Try to run it!
      Change Log: v1.0Initial release. v1.1 A lot of improvement for GAS2ASM converter and FASM header file. Add many C Run-Time library as inline asm subroutines. Add command-line to argc/argv parser for easy calling main() function. Add ability to redirect stdio. More C source code can work without modification in this version.
      Following open source projects are tested.
      And Yes, they can run as binary code library in AutoIt now.
      SQLite 3.8.5
      TCC 0.9.26
      PuTTY beta 0.63
      v1.2 Dynamic-link library (DLL) calling is supported now. 
      If the C program requires a DLL file to run, just put it together with the source file. BinaryCall Tool will searches *.dll and exports all the symbols in these DLL files automatically. Of course, you need these DLL files when run the output script. However, it also works if you loaded them by last version of MemoryDll UDF. To add more Windows API library easily by editing the ini file. Better error handling and more error messages in output script. Add zero padding to avoid short jumps that crash the relocation table. BinaryCall Tool accepts drag and drop files now. Some small bug fixed.  
      BinaryCall 1.0.zip
      BinaryCall 1.1.zip
      BinaryCall 1.2.zip
×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.