RUTIS Engine (Scripting) [WinCE spinnt]

[Florian Hämmerle]

Herzlichen Glückwunsch auch aus Österreich! +haha+ vielleicht nutzt nächstes Jahr ja jemand RUTIS um JF zu gewinnen :)

Schöne Grüße, Florian

[Mithrandir]

Hut ab, sowas schaffen die wenigsten. ;)

[olee]

DANKE :mrgreen:

@Daniel:
Freut mich das gerade von dir zu hören oh großer Meister :stupid: (EDIT: Daniel aus post#80 ^^)

Nebenbei möchte ich auch mal bekanntgeben, dass eine Neue Version von RUTIS hochgeladen wurde.

Außerdem werde ich in der nächsten Zeit weniger an RUTIS arbeiten, sondern an einem neuen Projekt.

Das wird eine Game-Engine, die RUTIS ausgiebig verwendet.

Geplant ist, mit dieser Game-Engine dann ein Echtzeit-Strategiespiel und eventuell eine neue Auflage von LOZ zu machen.

Die Entwicklung der Engine ist schon recht weit vorran geschritten.

Der RUTIS-Support ist schon fast vollständig integriert.

So lassen sich praktisch schon kleine Spiele ausschließlich mit Scripten erstellen!!

Ich werde also in der nächsten Zeit an diesem Projekt arbeiten, aber dabei natürlich RUTIS auch weiter entwickeln,
da es ja ein Teil der Engine ist.

EDIT:
@Florian Hämmerle:
In meinen Augen HAT Rutis gewonnen, nur muss man auch mal den kleinen ne chance lassen ... wobei ...
Ich hab mit dem gewinner nach der Siegerehrung geredet und gemeint, das war ja eig ne recht simple sache die er da gemacht hat...
Er meinte ja - er wär selbst überrascht, das er gewonnen hat :wink:

MFG

[Daniel]

Also Björn, ein Kommentar sei mir noch gestattet:

Zitat:

[...]Alles in allem war es 3 wunderbare Tage, die durch einen Besuch im McDonalds nach der Veranstaltung perfekt abgerundet wurden[...]

... :shock:




;-)
:cheers:

[olee]

Was kann ich dafür?

Die haben nach der Siegerehrung gesagt, es gäbe was zu Essen ...

Stattdesswen gabs da nur kleine Mini-Firkadellen und andere kleine Kaltspeisen

Und das war so schnell weg - man konnte unmöglich davon Satt werden :shock:

MFG

[Mithrandir]

Zitat:

Zitat von olee

@Daniel:
Freut mich das gerade von dir zu hören oh großer Meister :stupid: (EDIT: Daniel aus post#80 ^^)

Und ich hatte mich schon so gefreut, dass endlich jemand meine wahre Bestimmung erkannt hat... :cry:

[olee]

Ich hab mich heute mal etwas mehr mit SVN beschäftigt.

Nachdem ich schon seit einer Weile dank NamenLozer freude auf SVN gefunden habe, hab ich jetzt mal RUTIS als SVN Projekt hochgeladen.

Es ist zu finden unter http://www.xp-dev.com/sc/77518

MFG

[olee]

Ich dachte ich melde mich mal wieder :hi:

Nachdem ich in letzter Zeit leider nicht so viel Zeit zum Programmieren hatte, möchte ich nun etwas weiter an RUTIS arbeiten.

Das fängt nun damit an, das ich RUTIS wieder für WinCE (Pocket PC) rausbringen möchte, da die einzige existierende Version von RUTIS für PPC sehr alt ist (SEHR alt :oops:).

Ich habe eben erst vor ca. 15 min angefangen und schon läuft der erste Test ("Hallo-Welt") auf meinem PPC.

Leider sind wohl noch einige Fehler vorhanden.

Wer es dennoch einmal testen möchte, kann sich den aktuellen Stand über SVN holen oder mich kontaktieren.
Bei größerer Nachfrage würde ich die EXE und Co. auch hier ab und zu hochladen bevor ich eine stabil-laufende Version erreiche.


Mit freundlichen Grüßen

[olee]

So langsam geht es vorran mit der WinCE Version von RUTIS.

Doch leider hänge ich an einem großen Problem.

Anscheinend kann WinCE Variablen nicht außerhalb ihres Rasters abfragen.

Beispiel:

Delphi-Quellcode:

var
  Data : Array [0..64] of Byte;
begin
  //Die folgenden Befehle funktionieren alle problemlos
  PCardinal(@Data[0]) := 1;
  PCardinal(@Data[4]) := 2;
  PCardinal(@Data[8]) := 3;
  ...
  //Die folgenden Befehle verursachen auf WinCE mindestens mal eine AV (wenn nicht schlimmer)
  PCardinal(@Data[1]) := 1;
  PCardinal(@Data[3]) := 2;
  PCardinal(@Data[7]) := 3;
end;

Ich hab bisher keine einzige möglichkeit gefunden, das Problem zu umgehen - bzw keine effektive.

Ich habe das ganze unter Win32 im Debugger mal geprüft:
Die AV tritt bei einem AMS Befehl wie MOV [EAX], ESI auf

Das ganze ergibt iwie keinen Sinn.

Auffällig ist noch, das der Fehler nicht nur auf einem echten PocketPC auftritt, sondern auch im Windows Device Emulator, wo ich das Programm meistens teste.

Ich hoffe jemand hat ne Idee was man dagegen machen kann, bzw wo dieses Problem herkommt.

PS: Ich nutze Free-Pascal (Lazarus) zum kompilieren

MFG

[Neutral General]

Hallo,

Sicher, dass es

Delphi-Quellcode:

MOV [EAX], ESI

ist? Dieser Befehl macht meiner Meinung nach keinen Sinn und dürfte gar nicht existieren :shock:

[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:

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

[olee]

Genau dieses "misaligned data" hab ich auch als Fehler bekommen ab und zu...

Aber was soll man da dann nur machen....

Es scheint so als bleibt mir nichts anderes übrig, als alle Daten auzurichten...

Aber was mich wundert ist, das das Problem auch auf dem emulierten WinCe auftritt :gruebel:

Ich werde es weiterhin versuchen.

bisher hab ichs eh durch ausrichten der Daten soweit zum laufen gebracht.

Nur...
was mache ich dann mit packed records?????

Fragen über Fragen :wall:

MFG

[Namenloser]

Zitat:

Zitat von 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.

Das heißt, solange du nur einzelne Bytes abrufst, funktioniert alles? Das deutet dann wohl darauf hin, dass für jeden Datentyp das "Raster" ein Vielfaches der Größe des Datentyps beträgt. [edit]okay, anscheinend ist es dich immer 32 bit, laut Poelsers Link)[/edit] Ich fürchte fast, gegen solche hardwareseitigen Einschränkungen wirst du nicht viel machen können. Entweder du kopierst die Bytes einzeln, oder du musst irgendwie dein Stackformat so verändern, dass es ins Raster passt. Ich würde es zunächst mal mit der ersten Variante probieren, um zu schauen wie schnell oder langsam es wirklich ist, bzw. ob es überhaupt einen nennenswerten Unterschied macht. [edit] Hast du es mal mit dem auf der verlinkten Seite beschriebenen unaligned-Keyword probiert?[/edit]

Zitat:

Zitat von olee

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.

Das passiert bei Arrays aber auch. Würde es denn aber nicht reichen, einfach eine maximale Stackgröße festzulegen? Ist in "echt" doch auch so - deswegen gibt es ja auch einen Stacküberlauf, wenn du eine Funktion zu oft rekursiv aufrufst. Alternativ könntest du den Stack natürlich dynamisch in der Größe verändern, aber dann müsstest du bei jeder Größenänderung alle gespeicherten Adressen anpassen. Das gilt aber wie gesagt unabhängig davon, ob du die Speicherbereiche über Arrays, Streams oder sontwie alloziierst.

[olee]

Mein Stack hat eine halb-feste Größe.

Während der Ausführung reserviert meine Stack-Class Speicherblöcke mit einer
beim Erstellen des Stacks vorgegebenen Blockgröße.

Deswegen muss eine Adresse (als Pointer) auf eine Variable im Stack auch über die Array-Property
Data[<Stack-Adresse>] ausgewertet werden.
Diese Funktion prüft, auf welchem Stack-Block die gewünchte Adresse liegt
und gibt das entsprechende Ergebnis zurück.

Aber dieses unaligned_Keyword scheint genau das zu sein, was ich brauchte.

Ich werde dennoch (der Geschwindigkeit wegen) versuchen, die Variablen weitestgehend am Raster auszurichten.

Es stellt sich mir jetzt nur die Frage, was schneller ist:

Entweder immer mit unaligned auf die Werte zugreifen, oder vorher eine Prüfung durchführen, ob die Variable auf dem Raster liegt und dem entsprechend unaligned verwenden oder nicht.

Ich schätze aber 1. ist schneller, da unaligned bei schon ausgerichteten Werten wohl nix macht.

EDIT:
VERDAMMT ich glaubs nicht!
Das funktioniert so wirklich!!!!
VIELEN DANK das war eine große Hilfe!!

Ich werde nun mal sehen wie ich das auf die Reihe krige.
Am meisten Kopfschmerzen bereitet mir nun die Frage, wie ich das nutzen kann, ohne das sich das Projekt nicht mehr mit Borland-Delphi kompilieren lässt.
{$Ifdef WinCe} überall einzubauen wäre eine riesige Arbeit.
Vielleicht ließe sich ja sowas mit einer Funktion realisieren, die sich je nach WinCe oder nicht-WinCe unterscheidet.
Gibt es da nicht auch so was wie Inline-Funktionen, sodass ich das ganze nutzen kann, ohne eine Menge calls?
Leider kenne ich mich mit diesem inline nicht aus.

EDIT-2:
Mir ist gerade aufgefallen, das das doch einigermaßen geht:
Indem ich das so schreibe:

Delphi-Quellcode:

  {$ifdef WinCE}unaligned{$endif}(PCardinal(@Data[adr])^) := val;
  unaligned(PCardinal(@Data[adr])^) := val; //So sähe es mit WinCe aus -> lässt sich kompilieren
  (PCardinal(@Data[adr])^) := val;          //So sähe es ohne WinCe aus -> die Klammern stören Delphi ja nicht

Das solle nicht dermaßen viel arbeit sein.

MFG und VIELEN DANK für die Hilfe (vor allem @Poelser)

[olee]

Das ist aber sehr schade...

Delphi kommt mit meinem ganannten Beispiel dort nicht zurecht.

Wenn ich so etwas wie

Delphi-Quellcode:

(PCardinal(@Data[adr])^) := val;

schreibe sagt der: "[Pascal Fehler]: E2064 Der linken Seite kann nichts zugewiesen werden"

Also bleibt mir da fast nur noch eine Variante mit dem inline oder ich muss das ganze dann so schreiben:

Delphi-Quellcode:

{$ifdef WinCE}unaligned({$endif}PCardinal(@Data[adr])^{$ifdef WinCE}){$endif} := val;

:wall:

EDIT:
Gute Neuigkeiten!

Das mit der inline-Funktion funktioniert gut (zumindest beim auslesen von Werten):

Delphi-Quellcode:

function GetPCardinal(const Adr: PCardinal): Cardinal; inline;
begin
  {$ifdef WinCE}
  Result := unaligned(Adr^);
  {$else WinCE}
  Result := Adr^;
  {$endif}
end;

Function TRutisStack.PopCardinal : Cardinal;
Begin
  //So sah die alte Zeile aus:
  Result := PCardinal(Data[Top - 4])^;  

  //Und so die neue
  Result := GetPCardinal(Data[Top - 4]);  //Die neue Anweisung, die am ende dennoch die 
                                          //gleichen Assembler-Befehle ergibt dank inline
  Pop(4);
End;

MFG

[mastaraymond]

Hallo,

Meiner Deutsch ist nicht so gut, aber ich darf etwas fragen. Kannst du dieser patch anbringen?

grüße,

Raymond

Delphi-Quellcode:

Index: RUTIS_Classes.pas
===================================================================
--- RUTIS_Classes.pas   (revision 23)
+++ RUTIS_Classes.pas   (working copy)
@@ -134,6 +134,7 @@
     //================================================
     Property CompilerError  : Boolean Read GetCompilerError;
     Property Error  : ERutisCompilerError Read fCompilerError;
+   Property ScriptError : Boolean Read fScriptError
   End;
 
   TRutisCompiler = Class
@@ -1466,7 +1467,7 @@
 Begin
   Result := (Address < 0) or (Address > ScriptData.Stack.Top);
   If Result Then
-    ScriptMessage('Address Error (Address ID = ' + IntToStr(Address) + ')');
+    ScriptMessage('Address Error (Address ID = ' + IntToStr(Address) + ')', etRuntimeError);
 End;
 
 Function TRutisEngineBase.GetStackLvlAddress(Address, Level : Integer) : Integer;
Index: Rutis_Engine.pas
===================================================================
--- Rutis_Engine.pas   (revision 23)
+++ Rutis_Engine.pas   (working copy)
@@ -308,7 +308,7 @@
   fLastAdress   := Pointer(ScriptData.Stack.ReadCardinal(src));
   If GetExtAddrRange(fLastAdress) = -1 Then
   Begin
-    ScriptMessage('Address Error');
+    ScriptMessage('Address Error', etRuntimeError);
     exit;
   End;
 
@@ -320,7 +320,7 @@
   fLastAdress := Pointer(ScriptData.Stack.ReadCardinal(ScriptData.Stack.Top - 4));
   If GetExtAddrRange(fLastAdress) = -1 Then
   Begin
-    ScriptMessage('Address Error');
+    ScriptMessage('Address Error', etRuntimeError);
     exit;
   End;
 End;
@@ -1088,7 +1088,7 @@
 Begin
   If ScriptData.CurrCmd.P1 <= 0 Then
   Begin
-    ScriptMessage('Error - OpEnumToSet');
+    ScriptMessage('Error - OpEnumToSet',etRuntimeError);
     exit;
   End;
   bit := ScriptData.Stack.PopByte;
@@ -1649,7 +1649,7 @@
     intDouble  : Val2   := ScriptData.Stack.PopDouble;
     intExtended  : Val2 := ScriptData.Stack.PopExtended;
   Else
-    ScriptMessage('Comparison Error');
+    ScriptMessage('Comparison Error',etRuntimeError);
   End;
 
   Case TRutisIntType(ScriptData.CurrCmd.P2) Of
@@ -1669,7 +1669,7 @@
     intDouble  : Val1   := ScriptData.Stack.PopDouble;
     intExtended  : Val1 := ScriptData.Stack.PopExtended;
   Else
-    ScriptMessage('Comparison Error');
+    ScriptMessage('Comparison Error',etRuntimeError);
   End;
 
   Case TOperatorCode(ScriptData.CurrCmd.P1) Of