RUTIS Engine (Scripting) [WinCE spinnt]

[olee]

DIES IST DIE ALTE VERSION VON RUTIS
Die neue Version gibts hier: RUTIS v2
----------------------------------------------
Hi,
Hier möchte ich euch eines meiner größten Projekte vorstellen.

RUTIS

Die "RunTime Script Engine" (RUTIS Engine) dient dazu, Scripte zur Laufzeit zu compilieren und auszuführen, um z.B. Die Funktionen von Programmen zu verändern, ohne diese neu zu compilieren.
Durch eine sehr hohe Geschwindigkeit lassen sich sogar ganze Programme allein mit einem solchen Script erstellen.
Die RUTIS Engine kann mehrere Compiler unterstützen wobei der Standardcompiler mit einem Delphi/Pascal Syntax arbeitet.

- - - HINWEIS: INFOS ETWAS VERALTET - WERDEN BEI GELEGENHEIT KORRIGIERT - - -
RUTIS bietet eine große Funktionsvielfalt:

• Globale sowie lokale Variablen
• Verschachtelbare Funktionen und Methoden, die auch rekursive Algorithmen lösen können.
• Beliebige Deklaration von Records
• Unterstützung von Pointern und Arrays
• Einfache Verknüpfung von Hostprogramm und Script mittels speziellen, beliebig erstellbaren Verbindungsfunktionen.
• NEU: Methode-Variablen (bisher jedoch nur parameterlose Prozeduren)
• NEU: Formular Interface, wodurch sich ganze Anwendungen mit GUI erstellen lassen!
• NEU: Aufruf von DLL-Funktionen über die deklaration im Script als 'external' ! (Hier ein DANKE an 'Astat')
• uvm.

Das sollte vorerst an Informationen reichen.

RUTIS PROJEKTSEITE (Downloads, Infos usw.)
SVN-Portal: http://www.xp-dev.com/sc/77518

INFO : RUTIS unterliegt einer Creative Commons BY-NC-SA (DE) Lizenz
INFO 2: Die nachfolgenden Links könnten des öfteren nicht funktionieren, da sie nach jedem neuen Upload ungültig werden. Auf der Projektseite dagegen sollten
die Downloadlinks immer funktionieren. Ich entschuldige mich hier auch für eine solche Faulheit, die Links nur selten zu aktualisieren ^^
RUTIS Setup 1,04 MB RUTIS (zip) 1,28 MB RUTIS (Source) 2,08 MB

MFG

[olee]

Also das ist der Befehl, wie er im Delphi-Disassembler angezeigt wurde.
EAX enthält dabei die Adresse im Stack, die von einer Funktion vorher ermittelt wurde und ESI den Wert, der da hin geschrieben werden soll.
Das ganze sieht im Delphi-Code so aus:

Delphi-Quellcode:

Procedure TRutisStack.PushCardinal(Val : Cardinal);
Begin
  PCardinal(Data[Push(4)])^ := Val;
End;

Push gibt als Result die Stack-Adresse (von 0 an gezählt) zurück und
die Array-property Data gibt zu einer Stack-Adresse die absolute Adresse als Pointer zurück.

Der gesamte ASM Code sieht dann so aus:

Code:

Rutis_Defs.pas.1628: Begin
00493D48 53               push ebx
00493D49 56               push esi
00493D4A 8BF2             mov esi,edx
00493D4C 8BD8             mov ebx,eax
Rutis_Defs.pas.1629: PCardinal(Data[Push(4)])^ := Val;
00493D4E 33C9             xor ecx,ecx
00493D50 BA04000000       mov edx,$00000004
00493D55 8BC3             mov eax,ebx
00493D57 E804FCFFFF       call TRutisStack.Push
00493D5C 8BD0             mov edx,eax
00493D5E 8BC3             mov eax,ebx
00493D60 E887F2FFFF       call TRutisStack.GetData
00493D65 8930             mov [eax],esi
Rutis_Defs.pas.1630: End;
00493D67 5E               pop esi
00493D68 5B               pop ebx
00493D69 C3               ret

MFG

[olee]

EDIT: Sry Doppelpost - war ein Versehen
Ich habe mal (wieder) eine kleine Testanwendung zu diesem Problem programmiert:

Dabei handelt es sich um folgenden simplen Code:

Delphi-Quellcode:

var
  Data  : Array [0..128] of Byte;

procedure TForm1.BtnWriteClick(Sender: TObject);
var adr,val: Cardinal;
begin
  adr := StrToInt(EdAddress.Text);
  val := StrToInt(EdValue.Text);
  PCardinal(@Data[adr])^ := val;
end;

procedure TForm1.BtnReadClick(Sender: TObject);
var adr,val: Cardinal;
begin
  adr := StrToInt(EdAddress.Text);
  val := PCardinal(@Data[adr])^;
  EdValue.Text := IntToStr(val);
end;

Wenn man nun ins Editfeld für die Adresse Werte wie 0,4,8,12,... eingibt, lassen sich die Werte problemlos in Data eintragen.
Sobald man aber von diesem Raster abweicht (also z.B. als Adresse 1 eingibt), wird das Programm umgehend ohne jegliche Fehlermeldung terminiert.

MFG

[Namenloser]

Ich vermute mal, dass Arrays unter WinCE anders verwaltet werden. Du gehst bei dir davon aus, dass im Speicher immer alle Felder direkt hintereinander stehen, anscheinend ist das unter WinCE nicht so. Du könntest es mal mit dem Keyword packed probieren. Wenn das nicht hilft, wirst du dir eine andere Möglichkeit einfallen lassen müssen, um Speicher zu reservieren.

[olee]

Nein, die Daten liegen alle hintereinander im Speicher.

Denn das Problem tritt auch auf, wenn ich z.B. anstatt eines Arrays ein Record nehme oder auch nur einen Int64 Wert und da ein Cardinal außerhalb des Rasters abfrage.

MFG

[Namenloser]

Wie ist es, wenn du Daten aus einem Memorystream liest?

[olee]

Das ist eine sehr gute Frage.

Nur...

Ein Memory-Stream wär viel langsamer als Stack und es fehlt eine Wichtige Eigenschaft:

Der Speicherbereich vom Stack darf seine Adresse nicht verändern - also nicht durch ein Realloc verschoben werden (wegen Pointern).

...

Ne mir fällt grad ein das geht nicht.

Der kopiert ja bei einem Stream ja einfach einzeln die Bytes.
Das könnte ich ja genau so gut mit meinem Stack machen.
Dann würde das auch vermutlich funktionieren.

Jedoch wär das ja viel langsamer und sehr uneffektiv.

MFG

[Namenloser]

Das sollte auch weniger ein Vorschlag zur Nutzung des MemoryStreams sein, sondern war eine Frage bzw. eine dezente Anregung. Denn beim Memorystream muss es ja zwangsläufig möglich sein, unabhängig vom Raster Daten einzulesen. Falls es dort funktioniert (was es ja wie gesagt eigentlich muss), könnte man sich ja mal anschauen, wie es dort gelöst wurde.

Nebenbei: Wieso sollte der Stream im Gegensatz zum Array einfach nur so zum Spaß die Position seines alloziierten Speicherbereichs verändern? Solange du die Größe nicht veränderst, bleibt der Streaminahlt am gleichen Ort. Umgekehrt kann auch das Array verschoben werden, wenn du die Größe veränderst.

[olee]

1.) Ich hab doch gesagt wie das beim Stream läuft:
Es werden x Bytes von A nach B kopiert - also alle Bytes einzeln.
Das funktioniert auch bei meinem Stack ja problemlos.
Aber ich möchte ja direkt auf die Variablen zugreifen, die Per pointer ansprechen usw. und nicht immer byteweise kopieren, verarbeiten und wieder byteweise abspeichern.

2.) Wenn z.B. mehr Variablen angelegt werden oder eine Funktion sich sehr oft rekursiv aufruft, so muss der Stack vergrößert werden.
Und das passiert bei Speicherbereichen normalerweise über ein ReallocMem.
Lässt der Speicher sich aber an seinem aktuellen Speicherort nicht mehr weiter vergrößern, so muss der ja verschoben und sein inhalt kopiert werden. Das darf aber in RUTIS nicht passieren.

MFG

[Hawkeye219]

Hallo,

ich beschäftige mich zwar nicht mt der WinCE-Programmierung, kenne das Problem aber aus der Zeit der "alten" Motorola-CPUs M680xx. Bei ihnen waren Wort- und Doppelwort-Zugriffe nur auf geraden Adressen möglich. Vielleicht ist dies ja auch hier die Ursache des Fehlers: klick

Gruß Hawkeye

[Poelser]

Zitat von Hawkeye219:

ich beschäftige mich zwar nicht mt der WinCE-Programmierung, kenne das Problem aber aus der Zeit der "alten" Motorola-CPUs M680xx. Bei ihnen waren Wort- und Doppelwort-Zugriffe nur auf geraden Adressen möglich. Vielleicht ist dies ja auch hier die Ursache des Fehlers: klick

Ich denke auch, das es so etwas ist. Wir haben z.B. Probleme mit einem Asus CE-Gerät, auf dem die Lazarus-Programme sporadisch abstürzen mit einem Fehler, der in etwa "Privileg Violation or Misaligned Data" lautet. Andere Geräte laufen problemlos mit unserer Software

CU, der Poelser