Autoit zu C++ konverter

Ich.
Hab mich schon vor einiger Zeit mal rangesetzt und bislang funktioniert es auch einigermaßen. Also if, while, do-while, for, Funktionen und so funktioniert schon ganz gut.

Das ganze System funktioniert so:
Es gibt eine Variablenklasse, die alle in AutoIt vorhandenen Typen annehmen kann.
Alle nativen Funktionen werden als C++-Funktionen geschrieben und immer haben alle Parameter sowie return-value diesen Typ.
Das Skript wird konvertiert, als Header werden nur die Funktionen+Variablenklasse eingesetzt, damit es keine Überschneidung mit den Namen gibt. Dann wird es kompiliert und mit den vorkompilierten Funktionen zu einem ganzen Programm gelinkt.

Übersichtlich ist der Code aber nicht. Aus

Func Test()
For $i=0 To 3
MsgBox(0, "", $i*2)
Next
EndFunc

wird

//Dieses ist das konvertierte AutoIt-Skript
#include "AutoIt.h"


namespace AU
{
	Variable test();




	void AUMain()
	{
		;
		test();
	}


	Variable test()
	{
		{
			Variable stop(Variable(3));
			Variable stepval(1);
			for (Variable $i = Variable(0); intern::AU_FOR_COMPARISON($i, stop, stepval); $i += stepval)
			{
				msgbox(Variable(0), Variable(L""), $i*Variable(2));
			}
		}

		return Variable();	// Always return anything
	}


}

Ich könnte den Quellcode veröffentlichen, sodass wir alle zusammen daran arbeiten können.
Leider habe ich kaum kommentiert und ohne Wissen, warum ich dies und jenes gemacht habe, ist es am Anfang schwer zu verstehen.

0.0 - Klar wär das ne geile Idee, aber ich denke die Umsetzung ist unmöglich.
Jede vorhandene UDF umzuoden wäre eine Höllenarbeit, die Anpassung durch if, while, ... wäre auch code unübersichtlichkeit ³ ...
Und dann das debuggen bei 2k Code :o

@Matthias Wenn der Compiler funktioniert und mit Funktionen umgehen kann, brauchst du mit den UDFs gar nichts mehr machen, die würden dann automatisch mit kompiliert werden.

Funktionen und alles werden einfach mitübersetzt.
Nur die nativen Funktionen müssen noch extra geschrieben werden.

Ich hab mir schon überlegt, später noch eine Möglichkeit einzubauen, um neue Funktionen hinzuzufügen, die auf die gleiche Methode aufgerufen werden, wie die nativen, sodass man dabei z.B. Funktionen aus Dlls zu laden ohne den enormen Overhead durch DllCall.

Also vor allem wäre genial, eine DLL mit AutoIt erstellen zu können

Könnte man damit auch. Man muss nur noch einige zusätzliche Sprachelemente einführen, um CallingConvention, Typ des Rückgabewertes und Typ der Parameter anzugeben.
Man könnte auch Programme für Linux schreiben, allerdings würden dann nur die mathematischen, string- und einige Datei-funktionen funktionieren.

Um sowas kümmere ich mich aber erst, wenn alles stabil läuft und (fast) alle Möglichkeiten des Original-AutoIts implementiert sind.

Hi,
interessantes Thema, vor allem mit dem Hintergrund der Frage, wozu man einen AutoIt-C-Konverter braucht, der das KOMPLETTE Script kompiliert.
Denn das komplette Script mit sämtlichen nativen Funktionen nach C konvertiert, bringt einem (siehe Marthog´s Beispiel).....nichts!
Die Gründe um AutoIt zu benutzen sind vielfältig, die Einschränkungen eher minimal.
Da wären einmal die Größe des "kompilierten" Scripts in KBytes, da lasse ich mich jetzt nicht drüber aus, ich zweifle einfach an, dass dieses Thema heutzutage noch jemanden ernsthaft interessiert.
Weiterhin steht das Thema Ausführungsgeschwindigkeit im Raum, und da hat AutoIt teilweise Defizite.
Wieso aber nur teilweise?
Schauen wir uns mal x-beliebige der in den letzten Wochen hier im Forum geposteten Scripte an. Hauptsächlich gehts um GUI´s, Dateifunktionen, Webseiten-Gedöns usw.
Würde bei diesen Scripten eine Konvertierung nach C etwas bringen, Geschwindigkeitstechnisch gesehen? Auf keinen Fall! Solange User-Interaktion das Script bestimmt, ist Geschwindigkeit absolut kein Thema. Usability ist dann ein Thema
Die allermeisten nativen AutoIt-Funktionen sind, wie schon festgestellt, gewrapperte WIN-API-Calls. Ob jetzt C oder AutoIt das API callt, bleibt von der Ausführungsgeschwindigkeit gleich.
Aber WAS ist denn nun bei AutoIt so "langsam"?
Langsam sind immerwiederkehrende Berechnungen in langen Schleifen, in denen das Script viel Zeit verbringt, die sogenannten "inner Loops". Ich behaupte jetzt einfach, dass in den allerwenigsten dieser inner Loops die dort gecallten nativen (also API- ) Funktionen ein Problem sind, sondern eher die (mathematischen) Berechnungen oder Speicherzugriffe (wie z.B. bei Arrays).

Ob das Thema nun Bildbearbeitung, Kollisionsberechnung bei Spielen, Sortieraufgaben oder die Umsetzung beliebiger Algorithmen ist, in den allermeisten Fällen würde die "Übersetzung" nach C einen gewaltigen Geschwindigkeitsschub bringen, ohne dass 99,9% der API-Funktionen involviert sind!

Was also einen "Konverter" wirklich interessant machen würde, ist ein Übersetzer bzw. Compiler für Funktionen ohne bzw sehr wenige API-Calls.
Der Konverter würde den Inhalt der Funktion (bzw. des "inner Loops" ) nach C umwandeln, kompilieren (ggf. in eine DLL) und den Funktionsinhalt im AutoItscript durch einen DLL-Call ersetzen.
Man hätte ein schnell und einfach zu erstellendes AutoIt-Script, und die Möglichkeit, eklatant Geschwindigkeit zu optimieren, ohne dass der Code dadurch "unleserlich" wird.

Denn eins ist Fakt, ein langsames Programm wird nicht dadurch schneller, dass man es 1:1 nach C konvertiert!
Das AutoIt-Script

Func _randomcolor($hbitmap, $Color);setzt Bitmap in Farbe
For $b = 1 To 1000
For $h = 1 To 1000
_gdiplus_setpixel($hbitmap, $h, $b, $Color);API-Call
Next
Next
EndFunc ;==>_randomcolor

ist nach 1:1 Übersetzung nach C genauso langsam wie vorher mit AutoIt....
wobei ein

$Struct_Bitmap=DllStructCreate("uint [" & 1000 * 1000 & "]", $pointer_hbitmap);nichts weiter als ein Array

Func _randomcolor($Struct_Bitmap, $Color);setzt Bitmap in Farbe
For $b = 1 To 1000
For $h = 1 To 1000
dllstructsetdata($Struct_Bitmap, 1,$Color,$h*$b);Bytes im Speicher setzen
Next
Next
EndFunc ;==>_randomcolor

in C "übersetzt" geschätzt 100x schneller ist! Wobei es imho egal ist, ob man mit einer Struct oder einem Array arbeitet.

Dass heisst im Endeffekt, die Geschwindigkeitsvorteile von C müssen VOR der Konvertierung AutoIt->C im Script berücksichtigt und angepasst werden! Profiling lässt Grüssen!
Aber dieser Schritt ist im Gegensatz zu einem "Komplett-Konverter" nur ein Mückenschiss^^

Zusammenfassung:
Ein AutoIt->C - Konverter macht nur Sinn, wenn der Scripter das Script darauf ausrichtet! Dann kann er aber einfacher (und mit wesentlich verständlicherem Code) das Programm direkt in C schreiben.
Sämtliche API-Calls umzusetzen ist eine Menge Arbeit, die Geschwindigkeitstechnisch nichts bringt.
"Inner Loops" in z.B. eine DLL auslagern verändert den AutoIt-Code kaum und sorgt trotzdem für ein schnelles Script.

Ich finde den Ansatz von Ward sehr interessant, C Code Inline zu benutzen, um die von Andy dargestellten Geschwindigkeitsprobleme zu lösen.

D.h. z.B. ich muss eine Bitmap mit Pixeln füllen, tue dies aber mit Inline C oder von mir auch mit C++. Im Prinzip was Andy / Ward mit dem Inline ASM gebastelt hat.

Zurück zu moritz1243: was ist der Sinn mit AutoIt C++ Code zu erstellen? (nicht negativ gemeint!)

Gruß,
UEZ

Moin,

Ich benötige oft mehr Tempo in AutoIt als es hergibt.
Das verursacht automatisch, dass man lernt Probleme effektiver zu lösen (was man in einer schnelleren Sprache vernachlässigen kann wird hier zum Problem).

Die "harten" Sachen sind meistens genauso simpel. z.B. Grafikbearbeitung.
Solange ich keinen komplexen Filter, der seltsame Verzerrungen verursachen kann haben will, kann fast alles in AutoIt per Struct und simpler Mathematik in wenigen Zeilen gelöst werden. Anschließend setzt man sich hin und übersetzt das in ASM. (sofern man ASM etwas kennt weiß man beim schreiben des Testcodes in AutoIt schon wie man es machen muss, damit es später schneller ist oder leichter klappt).

Die "mittelharten" Sachen sind z.B. inner Loops bei Kollisionserkennungen.
Diese laufen idr nicht millionen Mal, sondern nur einige Hundert bis wenige Tausend mal ab. Diese Probleme machen mir die größte Sorge, da ich keinen Ansatz habe sie effektiv anzugehen. Man müsste die kompletten Daten als Structs vorliegen haben (dann geht eine DLL. In ASM würde das viel zu komplex je nach Aufgabe). Anschließend müsste man aber in AutoIt dennoch mindestens einen Schleifendurchlauf investieren um die Ergebnisse auszuwerten. (oder man hat ALLES in Structs. Dann wirds aber langsamer (Zugriff auf eine Struct braucht 1,5Mal so viel Zeit wie Zugriff auf ein Array) und unübersichtlicher.

Alles "leichtere" lässt sich entweder so elegant lösen, dass es keine große Zeit benötigt, oder ist durch eine DLL leicht ersetzbar. (z.B. wenn man das Ergebnis einer komplexen Rechnung braucht.)

Der großte Trick ist natürlich das auftreten von "mittelharten" Problemen zu verhindern. Man kann z.B. Bei 100 Gegnern und 100 Schüssen 10.000 Kollisionen testen. Man kann aber auch einen Puffer haben in den man beim Zeichnen der Gegner für jeden Gegner ein rotes Viereck malt. Anschließend testet man beim Zeichnen der Schüsse ob sie an einer Stelle gezeichnet werden an der es rot ist. Erst dann wird eine Kollisionsprüfung nötig um festzustellen welcher Gegner getroffen wurde. (hab ich z.B. bei TetrisInvaders so gemacht).
10.000 Kollisionstests = 100x Rotes Rechteck + 100x StructGetData + 0-10 Kollisionstests

Zitat von UEZ

Zurück zu moritz1243: was ist der Sinn mit AutoIt C++ Code zu erstellen? (nicht negativ gemeint!)

C++-Code wird richtig kompiliert. Der Interpreter fällt weg und der Code kann schneller ausgeführt werden.

Ok, vielleicht habe ich " Autoit zu c++ konverter" falsch verstanden.

Was ist genau mit " Autoit zu c++ konverter" gemeint?

Gruß,
UEZ

Wahrscheinlich, dass AutoIt zu C++ kompiliert wird und das Ergebnis dann wieder kompiliert wird, diesmal zu einer ausführbaren Datei.

Ja, der AutoIt-Code wird nach C++ konvertiert. Der entstandene Code ist nicht besonders gut lesbar und für C++-Verhältnisse auch nicht schnell, für AutoIt schon. Solche Konvertierer gibt es auch für andere Sprachen, z.B. Python.

AutoItC

Es ist noch in pre-alpha. Verbesserungsvorschläge und Hinweise auf Fehler nützen noch nichts, da ich andauern weiterarbeite und auf einem anderen PC bereits Änderungen vorgenommen, diese aber noch nicht übertragen habe.

Wenn ihr das Projekt beginnt, fangt doch am besten mit einem einfachen Programm an wie zum Beispiel Hello World von AutoIt zu C++ zu konvertieren. Und dann immer schwierigere Codes bzw. längere. Aber erst mal muss ja ein Konverter zu Stande kommen.

Zitat von volle

Wenn ihr das Projekt beginnt, fangt doch am besten mit einem einfachen Programm an wie zum Beispiel Hello World von AutoIt zu C++ zu konvertieren. Und dann immer schwierigere Codes bzw. längere. Aber erst mal muss ja ein Konverter zu Stande kommen.

Soweit bin ich doch bereits. Ich hab schon im dritten Post geschrieben, dass ich bereits

Func Test()
For $i=0 To 3
MsgBox(0, "", $i*2)
Next
EndFunc

konvertieren kann.

Hab den Thread nur überflogen.
Aber ich muss sagen für den Anfang, nice ! oO