Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Okt 19, 2018 14:55

Foren-Übersicht » Sonstiges » Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 30 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: Thorium Scripting Language
BeitragVerfasst: Fr Jun 06, 2008 17:45 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Dateien

Hallihallo,

Wie ich schon in meinem letzten Post im Strategiespiel-Thread angedeutet habe, arbeite ich jetzt an einer Scriptsprache. Der Grund dafür liegt darin, dass Lua zwar schön und gut ist, aber für meine zwecke unbrauchbar. Ich wollte einfachen und unkomplizierten Zugriff auf Objekte und deren Methoden und Feldern liefern, das klappte aber wegen dem bei Lua obligatorischen Garbage Collector leider nicht. Das Ergebnis: Nach ein oder zwei Sekunden hatte ich eine Diashow, mal ganz abgesehen von dem Speicherverbrauch den man hat, wenn 20000 Objektreferenzen ungenutzt im Speicher rumliegen. Daher habe ich mich entschlossen, eine eigene Scriptsprache zu entwickeln, die darauf zugeschnitten ist, in einer OOP-Umgebung zu arbeiten und die eine gute Schnittstelle zwischen Hostumgebung und Script bietet.

Ich habe es anfangs nicht gewagt, diesen Thread zu erstellen weil ich nicht sehr zuversichtlich war bezüglich meiner Fähigkeit und Ausdauer, diese Scriptsprache zu ihrem guten Ende zu bringen, aber mittlerweile komme ich vorran.

Also, das ganze nennt sich Thorium Scripting Language und wird in FreePascal entwickelt. Thorium ist eine kompilierende Scriptsprache, das heißt, der Scriptquelltext wird von einem Compiler zunächst in einen Bytecode übersetzt, der dann später von einer eigenen virtuellen Maschine ausgeführt wird. Das Hauptmerkmal ist die möglichst nahtlose Integration der Hostumgebung, die durch ausnutzen von RTTI Informationen und ein bisschen asm-Code realisiert wurde.
Die Sprache selbst orientiert sich an der C-Syntax, obwohl sie bei weitem nicht alle Features derselbigen unterstützt. Beispielsweise gibt es keine Referenzen (Pointer) und ähnliches. Dafür hat man aber wesentlich besser zu bedienene Strings als in C ;). Die einzelnen Scriptmodule (also Dateien) können ihre Funktionen sowohl public als auch private deklarieren, wobei sie nur im ersten Fall durch andere Module oder die Hostumgebung aufrufbar sind. Das gleiche gilt für Variablen und Konstanten.

Module können wie schon angedeutet andere Module importieren (mittels der "loadmodule" Anweisung). Dann wird der Zugriff auf alle public-Elemente des Moduls ermöglicht. Weiterhin kann ein Modul auch eine Hostumgebungsbiblitohek einbinden, welches dann den Zugriff auf die dort definierten Klassen, Funktionen, Eigenschaften und Konstanten ermöglicht.

Der aktuelle Stand ist der folgende:
Compiler:
  • Variablen
  • Konstanten
  • Funktionen (Deklaration und Aufruf)
  • Kontrollstrukturen: If, Switch, While, DoWhile, For
  • Break-Anweisung
  • Return-Anweisung
  • (Fast) beliebig verschachtelte Ausdrücke (maximale Verschachtelungstiefe von der Anzahl der virtuellen Register abhängig (Standard = 512))
  • Erweiterte Typen (mit Indicies und Feldern)
  • Register
  • Typen: String, Ganzzahlen, Floats, erweiterte Typen (Klassen aus der Hostumgebung)
  • Post-Compiling optimizer mit mehreren Optimierungsschemata, die auf den generierten Code angewandt werden um die Performance zu steigern
  • Auswertung von konstanten Ausdrücken
  • Fähigkeit kompilierte Scripte zu speichern und zu laden (mit Überprüfung von Kompatibilität mit der Hostumgebung und automatischer Versuch des Neukompilierens bei Inkompatibilität)
Interpreter:
  • Stable und eigentlich auch Mem-Leak-Frei
  • Register
Schnittstelle zur Hostumgebung:
  • Erzeugung von erweiterten Typen für die Scriptumgebung anhand von RTT-Informationen
  • Einbinden von Funktionen aus der Hostumgebung
  • Komfortables aufrufen von Scriptfunktionen
  • Wrapperloses Einbinden von Funktionen über NativeCall (inkl. Support für die Calling Conventions Register, StdCall und Cdecl, sowie array of * typen (auch array of const))
  • Einbinden von Record/Struct-Typen aus der Hostumgebung

Ein ganz wichtiger Punkt für die nächste zeit wird sein, den vom Compiler generierten Code portabel zu machen. Bisher sieht es so aus, dass der Code (zumindest, sobald erweiterte Typen, wie z.B. Klassen verwendet werden) nur in diesem einen Prozess funktioniert, da ich bisher rohe Pointer auf die Properties an die Anweisungen übergebe. Dies werde ich später auf Indicies umstellen, was dann leider aber bedeutet, dass die compilierten Scripts bei einer Änderung der Hostprogrammstruktur ebenfalls neu compiliert werden müssen.

So ich hoffe ich hab nix vergessen. Irgendwelche Fragen, Anmerkungen, Wünsche?

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Zuletzt geändert von Lord Horazont am Fr Okt 30, 2009 11:58, insgesamt 13-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Jun 13, 2008 16:57 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
So. Ich habe in den letzten Tagen neben der Schule auch mal wieder ein bisschen weitergemacht. Nun, Funktionsaufrufe Scriptintern werden jetzt Compiliert, auch Prototypen (= Forward Declarations) sind erlaubt und arbeiten einwandfrei. Auch kann man nun Module in andere Module importieren, mittels einer Require anweisung.

Die nächsten Schritte sind erstens die Einbindung von Funktionen aus der Hostumgebung und danach die Virtual Machine, damit ich auch endlich mal mehr sehe als nur einen Codedump :wink: . Und wenn das dann klappt werde ich vermutlich freudeschreiend durch das Haus hüpfen... Ich hoffe, wir haben dann keinen Besuch :wink:

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Jun 29, 2008 11:25 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
So. Die externen Funktionsaufrufe habe ich erstmal hintenangestellt und im moment gebe ich mich mit einem Stackdump nach jeder Instruktion zufrieden. Aber zumindest wird bisher alles ausgeführt, was ich so getestet habe. Es gab zwar einige Kinderkrankheiten und einen Konflikt mit dem FPC, der mir bei einer bestimmten Kombination aus Inline-Funktionen bei jedem zweiten Kompilieren einen Internal Compiler Error 217 rausgeworfen hat. Ich muss dafür noch eine lösung suchen, da das gerade die während der Laufzeit am häufigsten benutzten Funktionen betrifft und so eine Geschwindigkeitseinbuße bedeutet.
Ansonsten bin ich aber soweit zufrieden.

Der nächste Schritt sind dann externe Funktionen, dann externe Methoden. Und wenn das soweit läuft kommen Arrays dran.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Jun 30, 2008 16:24 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Okay... Nach einigen massiven Bugfixes (ich hatte den Interpreter zunächst rudimentär getestet) habe ich jetzt mal einen kleinen Performancetest gemacht und bin nicht sehr begeistert.
Test"szene" ist eine For-Schleife, die von 0 bis 1000000 zählt und ... nichts tut.
Ich habe den PerformanceCounter bemüht, um an Ergebnisse zu kommen.
Erschütternd: Hardcoded nimmt die Schleife müde 2.9ms in Anspruch.
Sobald ich das ganze aber im Script mache, brauch eich satte 1152.3ms, also gut eine Sekunde.

Dementsprechend werde ich jetzt mal versuchen, auf nähere Suche zu gehen, woher das kommt, d.h. jede "Instruktion" einzeln Zeitmessen und schauen, was bei rauskommt. Bis dahin ist die Weiterentwicklung (logischerweise) erstmal eingestellt. Ich muss erst herausfinden, wo die Schwäche liegt. Natürlich habe ich mit inline nicht gegeizt (ist ja auch notwendig). Wobei ich ja an einer eklatanten Stelle drauf verzichten musste und ich vermute, dass genau da das Problem liegt (ist die Instruktion, die einen Integer auf den Stack legt. Für den Vergleich in der Schleife ist das natürlich sehr wichtig).

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Jul 01, 2008 18:25 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Nun, nachdem ich erst einmal festgestellt habe, dass obige Messung schlichtweg falsch war (ich hatte verschiedene Codes innerhalb der Schleife verwendet), bin ich etwas motivierter. Aus dem Faktor 500 wurde der Faktor 200.
Nachdem ich meinen Assert-Testersatz (weil die Assertions nicht so liefen, wie ich das wollte) auch wieder deaktiviert habe, habe ich das ganze auf Faktor 180 senken können. Weitere Vorteile brachte eine Umstellung in der Codegenerierung, die für die inkrementation und dekrementation von Variablen zuständig war, und zwar bin ich damit auf Faktor 160 runter.

Der nächste Schritt im Optimierungswahn sind Register. Bisher habe ich sie für unnötig gehalten, aber wenn jedes mal wieder ein neuer Stackeintrag alloziiert und mit einem Integer gefüllt wird, ist das wohl etwas übertrieben. Statt dessen werde ich das in Registern zwischenspecihern.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Aug 03, 2008 16:53 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Okay, die Register sind etwas aufwendiger als erwartet. Hinzu kommt, dass ich jetzt so viel wie möglich auf registern auf bauen möchte und den Stack nurnoch in Ausnahmesituationen verwenden will (dazu gehören auch Funktionsaufrufe und ähnliches).

Ich bin dabei schon weiter als ich erhofft habe und arbeite nun am letzten Feinschliff für die Registerimplementation im Compiler. Danach muss ich noch die Virtual Machine umstellen aber vorher kommt noch etwas anderes (ich brauche zum Debuggen ne bessere ausgabe meines Fake-ASM, die muss differenzierter sein).

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Aug 04, 2008 17:46 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Die Register sind jetzt technisch komplett implementiert und werden auch schon mächtig verwendet. Es hat auch einiges gebracht, ich bin vom Faktor 160 auf Faktor 140 runter gekommen.

Über nacht kam mir auch noch die Idee, wie man relativ einfach einen Optimizer schreiben könnte, der den Code nachher noch einmal bearbeitet. Der Funktioniert auch wunderbar, in meiner Testszene senkt er den Faktor nochmal um 20 auf 120x.

Weiter geht es jetzt folgendermaßen:
Zuallererst muss ich Arrays einbauen. Das hatte ich eigentlich schon im Zuge der Umstellung für die Register vor, der Plan ist allerdings gescheitert, weil meine anfängliche Implementationsidee leider nicht so wollte wie ich. Dann war ich aber so in Fahrt und habe die Handbremse einfach nicht gefunden, sodass ich einfach weitergemacht habe und die Arrays links liegen gelassen.

Wenn ich mit Arrays durch bin, werde ich Funktionsimporte und -exporte implementieren, das heißt, dass die Hostumgebung dem Script Funktionen zugänglich machen kann und umgekehrt. Ich habe dafür schon ein paar Klassenskelette rumliegen, die wollen aber noch mit Muskeln und Haut versehen werden (um in der Metapher zu bleiben ;) ).

Zu dann hoffentlich guter letzt werde ich mich noch einmal dem Optimizer zuwenden, der ja bisher nur ein einziges Makel des Compilers ausgleichen kann. Ich werde dafür wohl verschiedene Testscripts schreiben und dort nach Mustern suchen, die sich verbessern lassen.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Aug 17, 2008 17:10 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Aus dem leichten Ast beim "on the fly" Implementieren von Arrays ist nun ein ausgewachsener Baumstamm geworden, der mir gerade den Weg versperrt. Arrays benötigen vorallem eins: Intern verschachtelte Typendeklarationen, schließlich muss ein Array wissen, von welchem Typ es ist. Das ist aber mit Records nicht machbar, schon garnicht mit welchen mit einer Case-Anweisung drin. Da das dann auch keine normalen "Values" mehr sein können (die auch als Records definiert sind), überlasse ich die Arrays gleich den erweiterten Typen. Es wäre größtenteils einfach doppelte Arbeit und kaum noch vertretbar.
Schweren Herzens von einfachen Arrays verabschiedent wende ich mich nun den im- und exportierten Funktionen zu.

Aber es gibt auch etwas Gutes zu berichten. Und zwar habe ich mal die Compileroptimierungen von FreePascal hochgedreht und festgestellt, dass sich damit der Faktor nochmal locker um 40 senken lässt. Ich bin daraufhin gleich auf die Manual losgegangen und habe geschaut, was wo optimiert wird um zu gucken, was ich selber da machen kann. Sieheda, Jumptables bei Cases anstatt auswertungen. Das klingt doch klasse, sowas werde ich implementieren (habe dazu auch schon einige Feldversuche gemacht), sodass man nicht die Optimierungen anhaben muss und außerdem das ganze auch noch mit Delphi gut klappt (ich weiss nicht, was Delphi an dieser stelle tut) - wobei der Delphi-Support von Thorium eh noch in den Sternen steht, da gibt es bestimmt einige inkompatibilitäten (z.B. benutze ich diverse FP-Only Operatoren).

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Okt 05, 2008 23:04 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Okay.
Nach einigen Stunden beziehungsweise Tagen intensiven Programmierens habe ich nun einiges zu erzählen.

1. Mir ist aufgefallen, dass meine Instruktionen ungewollterweise die gleichen wie in einer Typlosen Scriptsprache sind. Also umgestellt, aus den überschaubaren 40 mal schnell 65 Instruktionen gemacht. Die Implementation ist noch nicht vollständig und auch nicht ganz fehlerfrei fürchte ich, aber fürs erste reicht es.

2. Funktionsaufrufe sind nun endlich (und hoffentlich) fertig. Funktionen aus der Hostumgebung können den letzten Parameter als Varargs deklarieren, was in den Funktionen printf und format auch schon einwandfrei arbeitet.

3. Diverse optimierungen, vorallem in der Virtual Machine und in den Flow-Control codes.

4. Faktor auf ~90 gesenkt.

5. die 10000 Zeilen Sourcecode in der Thorium.pas geknackt...

So... Jetzt die doppelte Primiere: Ich lade den Beta-Code hoch. Das ist nicht nur der erste Code zu diesem Projekt sondern der erste Code zu überhaupt einem Projekt, welches ich hier protokolliere. Wie ich auch in den Dateien erwähnt habe, ist das Beta Code und wird wohl keinesfalls so arbeiten wie man es von ihm erwartet. Außerdem darf dieser Code nicht weitergegeben werden und nicht in eigenen Projekten verwendet werden (später wird das natürlich anders). Ich habe auch für die nicht-Lazarus-User die Exe mit eingebunden. Ich habe nicht getestet, ob der Code in Delphi kompiliert. Nach dem ganzen geschwafel gibts jetzt hier den Link: thorium-beta.zip.

Nen paar Kommetare wären nett :)

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 08, 2009 11:29 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Nach einer ganzen Zeit Funkstille zu Thorium kann ich nun melden, dass ich mal wieder dran saß.

Ich habe jetzt das Interface für Aufrufe von Scriptfunktionen aus der Hostumgebung komplettiert. Das geht mittlerweile auch ganz gut. Weiterhin habe ich diverse optimierungen am Compiler vorgenommen. Zum Beispiel kann dieser jetzt Ausdrücke auch schon weitestgehend zur Compiletime auswerten. Klappt leider nicht 100%ig, das ergebniss stimmt zwar immer, aber es ist nicht immer Möglich, einen Ausdruck auszuwerten.
Code:
  1. time = now * 60 * 24 * 1000

würde zum Beispiel nicht optimiert, während
Code:
  1. time = 60 * 24 * 1000 * now

optimiert werden würde. Faustregel: Ab dem ersten Ausdruck auf einer Operatorebene, der nicht konstant ist, wird nicht weiter ausgewertet. Ich wüsste auch nicht, wie ich das Lösen könnte.

Jetzt kann ich mich bald auf die Verwendung von erweiterten Typen stürzen, die zwar bisher vom Compiler verarbeitet wurden, aber in der Laufzeitumgebung noch nicht funktionstüchtig sind. Außerdem muss ich noch das ein oder andere am Compiler überprüfen, manchmal macht der ganz komische Dinge ;). Zum Beispiel baut er mir hier eine Endlossschleife in den code... Da muss ich auch noch genauer debuggen.

Auf jeden Fall lebe ich noch.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 14, 2009 12:28 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Was so ein paar Tage ohne Internet alles anrichten können. Nun habe ich in den letzten Tagen viel an Thorium gebastelt, woran LittleDave nicht ganz unschuldig ist ( ;) ). Jetzt habe ich es nahe einer Vollendung gebracht. Um herauszufinden, was noch fehlt, muss ich es nutzen - daher baue ich jetzt Nahtlos am Strategy Game weiter, wobei ich mir noch nicht sicher bin, wie lange das geht. Schließlich sind in zwei Tagen die Ferien auch schon wieder vorbei...

Also. Was hat sich geändert seit dem letzten Release?
1. Ich habe das Interface zu Klassen aus der Hostumgebung via TThoriumPersistent etwas ausgeweitet und verfeinert. Nun können auch Methoden übergeben werden (siehe dafür bitte die scripttest.pas. Um das OOP-Sample nutzen zu können, bitte in Zeile 610 in die beiden eckigen Klammern des Aufrufes die TestValue schreiben).
Was fehlt noch: Eine komfortable Möglichkeit, Konstruktoren zu übergeben.

2. Viele, viele Optimierungen. Die For-Schleife ist jetzt eine echte For-Schleife, die die Operanden des Vergleichs Cacht und damit viel schneller sein kann als eine While-Schleife (vgl. T_FORTEST4 und T_WHILETEST4 im Benchmark-Modus).

3. Kompilierte Scripte können nun gespeichert werden (passiert in scripttest.pas automatisch) und werden vom Compiler auch geladen, wenn sie in einem Require angefordert werden. Verwendungen von Werten aus der Hostumgebung werden beim Speichern mit in die Datei geschrieben und beim auslesen wieder im kompilierten Code geändert, was eine reibungslose Funktion garantieren soll (funktioniert recht zuverlässig).
Was fehlt noch: Möglichkeiten, Thorium zu sagen, wo es nach Dateien suchen soll bzw. ein Callback um die Dateien selber zu öffnen anstatt direkt TFileStream zu verwenden.

4. Benchmark-Modus: Im Download-Paket sind zwei Exe-Dateien mitgeliefert, die allein für Benchmarking gedacht sind. Dabei wird die testscript.benchmark.txt geladen und alle exportierten Funktionen unter zeitmessung ausgeführt. Vorher wird der Benutzer gefragt, wie oft ein Test ausgeführt werden soll (dann wird der Durchschnitt berechnet). Die Funktion compare_test wird nicht nur unter zeitmessung durchgeführt, sondern es wird auch ein Vergleich mit der Lua-Funktion in testscript.benchmark.lua (Nur bei der Test-Exe ohne .nolua dran) und mit der Hostumgebung durchgeführt.
Hinweis: Wenn der Code in der compare_test funktion angepasst wird, muss auch der Code in der Hostumgebung bzw testscript.benchmark.lua angepasst werden ;).

5. Variablen in Registern: Das wird nur in For-Schleifen verwendet, erhöht die Performance aber ungemein. Die Zählvariable wird in einem Thorium-Register abgelegt und der Zugriff erfolgt immer direkt auf dieses Register. Gerade, wenn die Zählvariable häufig verwendet wird, kann das einiges bringen, da Operatoren dann direkt auf das Register zugreifen können.

Ich glaube damit hat sichs jetzt. Mehr fällt mir gerade nicht ein. Der Code steht übrigens dieses mal unter der MPL 1.1, da ich mich Tests in "echten" Projekten auf keinen fall im Wege stehen möchte. Und hier der Download-Link:
http://www.sotecware.net/downloads/projects/thorium-rc1.zip

Kommentare und auch Fehlerberichte (vorallem, wenn jemand ein 64-bit System hat zum Testen, auch unter Windows, gerne gesehen :) ) sind dringend erwünscht. Gerade am Interface zur Hostumgebung kann ich jetzt noch vieles ändern. Wenn ihr also rumprobiert und euch etwas nicht gefällt, bitte her damit. Bis ich Thorium exzessiv in einer Hostumgebung testen kann, wird noch einige Zeit vergehen. Wenn ihr aber wunschlos glücklich mit Thorium seid, nehme ich das auch gerne zur Kenntnis :)

Gruß Lord Horazont
P.S.: Die Tests LD_TEST1 bis LD_TEST9 kommen von LittleDave, er benutzt diese, um seine eigene Scriptsprache zu testen. Ich hoffe, er hat nichts gegen die Verbreitung als Thorium Script ;)

P.S.S: Was mir gerade noch einfällt: Wenn ihr es nicht deaktiviert und Thorium dann neu kompiliert, benutzt es die Heaptrc um Memleaks zu finden. Wenn also in der Heaptrc mal etwas von einem Memleak steht, bitte die passende Sektion hier posten (das geht los mit dem Pfad zur Exe und den Parametern und endet entweder am Ende der Datei oder wenn der nächste Pfad da steht). Es können immer wieder Memleaks auftreten, daher bitte ich euch, das hier zu posten. Ich kann nicht alles selber finden ;)

P.S.S.S: Wenn ihr das Benchmarking macht, bitte an dem Zeitpunkt, wo ihr die Anzahl der Tests eingeben könnt, mit Hilfe des Taskmanagers die Priorität von Thorium auf Echtzeit hochsetzen (außer wenn ihr keinen Dualcore oder besser habt, dann ist Hoch vermutlich eher angebracht). Wenn ihr einen Vergleich mit Lua wollt, bitte die Lua5.1.dll in das Scripttest.benchmark.exe-Verzeichniss packen. Ansonsten die Scripttest.benchmark.nolua.exe starten.

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Mai 20, 2009 19:13 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Tja... Nun ist einige Zeit vergangen und ich habe eigentlich in den letzten Wochen garnichts an Thorium gemacht. Aber kurz nach dem Release hat sich hier noch etwas getan, was ich hier nun berichten will.

Zum Punkt 1 aus dem Post oben kann ich sagen, dass man nun auch "statische" Methoden an Thorium übergeben kann. Von daher, keine Probleme mehr in diese Richtung. Auch das Parsing von Ausdrücken wie "TThoriumRTTIType.Create" läuft einwandfrei.

Zum Punkt 3: Es gibt nun ein Event, welches man verarbeiten kann um Thorium einen Stream für ein zu öffnendes Modul zu geben. Wenn das nicht behandelt wird (ergo: man weist garnicht erst einen Handler zu), wird automatisch auf TFileStream zurückgegriffen. Wenn man aber nil zurückgibt, gibts ne Exception á lá "Cannot open module file 'bla'.".

Dann zu dem Punkt, der mit an Thorium schon immer an wichtigsten war und der jetzt wieder hinausgeschoben wird. Nahtlose integration der Hostumgebung ins Script. Also das Aufrufen von Funktionen der Hostumgebung ohne die notwendigkeit von Wrapper-Funktionen. Dafür entwickle ich eine Art miniscript, welches in den Thorium-Internen Funktionsobjekten abgelegt und dann beim Aufruf der Funktion aus dem Script heraus abgearbeitet wird. Dieses Script wird auf Aufruf der Hostumgebung erzeugt, nachdem man die Funktionsspezifikation festgelegt hat. Dieses Mini-Script ist dann dafür zuständig, dass die Parameter in der richtigen Reihenfolge aufm Stack und in den Registern landen. Ursprünglich wollte ich dafür ja die Bibliothek von Kevin Niehage verwenden. Nun habe ich aber festgestellt, dass es über das Miniscript wohl besser sein wird und dann kommt da noch dieses Problem hinzu: Mein großes Problem heißt aber hierbei 64-Bit Architektur. Dort verwenden jetzt doch tatsächlich stdcall und Co. die Register um Parameter zu übergeben. Ich bin da aber noch nicht ganz hinter alles gekommen. Wenn jemand eine gute Spezifikation dafür weiss, immer her damit!. Ich würde den Direct Call support nur ungerne auf 32-Bit beschränken.

Ich erhoffe mir hiervon, neben der unnötigkeit von Wrapper-Funktionen, auch einen, wenn auch kleinen, geschwindigkeitsvorteil, weil ein Call und hoffentlich auch die ein oder andere Instruktion ausgespart wird. Da das ganze hier über ein Mini-Script läuft wird hier die ein oder andere bisher vorhandene Schleife, der ein oder andere Vergleich auf die Ebene des Precompilings umgelagert. Passiert also nur einmal, nicht bei jedem Aufruf.

Ich hoffe, ich habe euch etwas den Mund wässerig gemacht :).

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Jul 04, 2009 14:52 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
So und hier bin ich auch mal wieder. Ich hab ja schon an anderer Stelle angedeutet, dass ich wieder an Thorium schraube - und die jungs ausm IRC wissen das sowieso, speziell waran, der mir immer als "wandelnde" ASM-Referenz zur Seite steht.

Das NativeCall Feature von Thorium kann nun als Stable bezeichnet werden. Nun kann man also ganz normale Pascal und C Funktionen aus dem Script heraus aufrufen, ohne das dafür ein Wrapper geschrieben werden muss. Dies erleichtert die Integration von großen Bibliotheken wie bswp. OpenGL oder LibXML ungemein. An der Schnittstelle zum Bekanntmachen der Funktionen werde ich heute und eventuell morgen noch viel ändern und arbeiten, daher gibts dazu jetzt kein Codebeispiel. Aber man kann jetzt aus einem Thorium Script heraus beispielsweise eine Funktion wie diese Aufrufen:
Code:
  1. procedure LibStd_printf(const S: String; const Args: array of const);
  2. begin
  3.   Write(Format(S, Args, DefaultFormatSettings));
  4. end;

Gehen wir davon aus, dass die Funktion als printf in Thorium registriert wurde, könnte ein Script, welches diese Funktion aufruft zum Beispiel so aussehen:
Code:
  1. public void main()
  2. {
  3.   int rnd;
  4.   rnd = random(10);
  5.   printf("The random number is: %d", rnd);
  6. }

(unter der Vorraussetzung, dass random irgendwo deklariert wurde).

NativeCall hat nur eine Einschränkung: Es funktioniert nicht (vollständig) auf Plattformen, die kein LittleEndian unterstützen. Es ist zwar theoretisch möglich, aber dadurch, dass das sehr viel Anpassungsarbeit erfordert und die Anzahl der Plattformen, die LittleEndian garnicht unterstützen doch recht gering ist, war es mir den Aufwand jetzt nicht wert.

Wie oben schon angedeutet stehen noch einige Änderungen aus. Ich möchte noch eine einheitlichere Schnittstelle für Bibliotheken der Hostumgebung schreiben. Bisher geschieht das ziehmlich dirty über TThorium.ExternalFunctionRegistry und TThorium.ExtendedTypeRegistry. Das ist insofern nicht befriedigend, da damit alle Dinge aus der Hostumgebung zwangsläufig in allen Modulen verfügbar sind, auch wenn diese das eventuell nicht explizit angefordert haben. Für diesen Zweck werde ich im Code einiges umstellen, zum Beispiel noch eine abstrakte Basisklasse unter TThoriumModule bauen und von dieser dann einen Typ ableiten, der eben solche Hostbibliotheken repräsentiert.

Ich hoffe, innerhalb der nächsten sieben Tage Thorium endlich als Version 1.0 releasen zu können. Ich hoffe, dass ich auch die Muße finde, eine Dokumentation zur kompletten Thorium API schreiben zu können.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jul 08, 2009 20:31 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
Jetzt ist es soweit. Thorium erreicht Version 1.0.0.0.

Ich habe in den letzten Tagen noch viel Feinschliff betrieben, nahezu die Hälfte der Identifier nochmal umbenannt, um dem über die Zeit entstandenen Code ein einheitlicheres Aussehen zu geben. Außerdem hab ich ein bisschen Code zwischen den Units hin und her geschoben und so noch ein wenig für Ordnung gesorgt.
Außerdem habe ich noch viele Bugs entdeckt und (hoffentlich) auch gefixt. Einige Performancetechnische Verbesserungen habe ich auch vorgenommen, die betrafen aber größtenteils den Compiler und nicht die Laufzeitumgebung.
Ein neues Feature hat es gerade noch in die 1.0 geschafft, nämlich das Komprimieren von kompilierten Thorium Skripten. Bisher nahmen die mehr als das Vierfache des Speichers vom Quelltext ein, jetzt sind sie meist kleiner. Der Performanceunterschied beim Kompilieren bzw Laden und Speichern von Skripten ist bei dieser kleinen Datenmenge praktisch nicht bemerkbar.

In dieser Version sind für die verschiedenen Anwendungsgebiete auch Beispiele beigelegt, um das Verständniss zu verbessern. Bisher habe ich nicht die Zeit gehabt, eine komplette Dokumentation zu Thorium zu schreiben. Ich hoffe daher einfach mal, dass die beigelegten Beispiele sowie (bezüglich der Bibliotheken) der Quelltext des thoriumlib-Packages ausreichend sind als Referenz. Ansonsten bitte melden.

Der Download ist auch im ersten Post verlinkt, aber der Vollständigkeit halber:
[ out of date ]
In den Archiven befinden sich nur Quelltextdateien. Da ich mittlerweile nur noch Linux habe, ist es glaube ich nicht allzu sinnvoll, Binaries anzubieten - die meisten von Euch können eh nichts mit anfangen. Für Lazarusnutzer empfehle ich, die beiden .lpk-Dateien in den unterordnern zu Packages zu kompilieren - dies wird dann dafür sorgen, dass die Thorium-Units überall verfügbar sind. Vorher werden sich auch die examples nicht kompilieren lassen (die haben die Packages als dependencies). Das ist die beste mir bekannte Methode, Units für Lazarus bekannt zu machen - und wesentlich plattformunabhängiger und Komfortabler als das Eintragen von Suchpfaden.
Thorium ist im moment nicht zu Delphi kompatibel. Wenn dies erforderlich sein sollte (von mir aus auch nur zu Testzwecken), werde ich mich da ran setzen (ist eigentlich nicht allzu viel, was man ändern muss).

greetings
ps: so, auf ne schöne runde gemetzel in diablo II mit Frase und i0n0s :)

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Aug 06, 2009 17:20 
Offline
DGL Member
Benutzeravatar

Registriert: Do Sep 02, 2004 19:42
Beiträge: 4158
Programmiersprache: FreePascal, C++
So... Während dem DGL-Treffen habe ich einen fiesen Bug gefixt bekommen, auf den mich Wilson kurz vor Abreise noch aufmerksam gemacht hat. Und zwar konnte es unter bestimmten Umständen auf 32bit zu Crashes kommen, wenn man NativeCall verwendet. Lustigerweise ist mir das während den Tests nicht passiert, nachdem Wilson es gemeldet hatte ist es mir aber doch auch aufgefallen.

Außerdem habe ich den Code mal etwas aufgeräumt. Auf dem Treffen wurde mir sehr deutlich klar gemacht, dass die Unit viel zu groß geraten ist. Ich habe Diagramme angelegt und stundenlang gegrübelt und bin zu dem Schluss gekommen, dass es außer Includefiles oder bösen Casts keine Lösung gibt, um das aufzuspalten. Es gibt einige notwendige Rückbezüge in der Klassenstruktur, die von den fast "höchsten" Klassen (TThoriumHostObjectType u.a. ) zu dem am meisten verwendeten Record (TThoriumType) führen. Da ich aber Includefiles nun wirklich nicht anwenden will und böse Casts den Code noch unleserlicher machen, als er durch Überlänge ist, steckte ich ein wenig in der Klemme.
Also habe ich das beste daraus gemacht. Ich habe so viel wie möglich in andere Dateien ausgelagert, um wenigstens *etwas* Ordnung in die Sache zu bringen. Weiterhin habe ich die einzelnen Klassengruppen nun sowohl im Interface als auch in der Implementation mit Code Regions und einem ausführlicheren Kommentar versehen. Außerdem hat jeder Typ auch noch einen eigenen kurzen Kommentar. Das hat den Vorteil, dass man zumindest mit Lazarus allein durch das Zeigen mit dem Cursor auf den Typ irgendwo im Code auch den Kommentar angezeigt bekommt.

Lange Rede kurzer Sinn: Thorium ist nun bei 1.0.1.0. Aus Faulheit gibts die Links dieses mal nur ganz oben im Headpost. Mit mit der Pos1/Home-Taste ganz einfach zu erreichen ;).

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant networkmy photostream
„Writing code is like writing poetry“ - source unknown


„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 30 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Sonstiges » Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.040s | 15 Queries | GZIP : On ]