HQ9+fuck Interpreter

[FAlter]

Hi,

ich habe mal schnell einen Interpreter für die Sprache HQ9+fuck zusammengezimmert. Er ist sehr quick&dirty.

HQ9+fuck ist eine Kombination der Programmiersprachen HQ9+ und brainfuck, welche die Vorteile beider vereint.

Der Interpreter ist ein Konsolenprogramm, an welches man den Namen der Textdatei (ASCII-Codierung) als Parameter übergibt, welche den Sourcecode enthält.

Im Anhang finden sich vorcompilierte Programme für Windows (x86 32 und 64 Bit) und Linux (x86 32 Bit), Beispielprogramme und eine Readme-Datei inklusive Erklärung der HQ9+fuck Sprache.

Der Interpreter ist auch teilweise Kompatibel zu reinen HQ9+ oder Brainfuck Programmen.
Brainfuck-Programme dürfen keine Zeichen H, Q oder 9 (in Kommentaren) enthalten oder sie müssen mit dem Schalter -bf gestartet werden. Sollten sie eine bestimmte Wortgröße erfordern, so muss der entsprechende Schalter angegeben werden.
HQ9+ Programme müssen in Großbuchstaben geschrieben sein (also nicht h oder q), da HQ9+fuck case-sensitiv ist (und natürlich dürfen sie auch keines der Zeichen -<>,.[] enthalten die aus Brainfuck entwendet wurden).

Das Programm steht unter der GPL.

Changelog:

Code:

[b]0.0.3[/b] - Eingabemethode ist schaltbar[list][*]Bei Problemen kann die Eingabenethode per -key umgestellt werden.[*]Vergesst die 0.0.2, jetzt das gleiche anders gelöst[*]FPC StdErr statt ErrOutput verwendet (letztere besteht angeblich nur aus Kompatibilität zu Delphi)[*]Exitcode / Errorlevel jetzt ohne den bekloppten halt Befehl[/list]
[b]0.0.2[/b] - Eingabe per ReadKey?[list][*]Jetzt ist es auch möglich (und im Standard so gemacht), beim compilieren ReadKey statt read zum Einlesen einer Eingabe zu nutzen. Leider funktioniert damit das Umleiten der Standardeingabe nicht mehr richtig oder so :-([/list]
[b]0.0.1[/b] - Speed![list][*]Grundlegende Designüberarbeitung: Der Interpreter interpretiert nun Bytecode (bzw. ein Array), welcher von einem Compiler erzeugt wird[*]Erarbeitung eines Konzepts für Optimierungen --> mehr Speed![*]Errorlevels teilweise dokumentiert[*]neue undokumentierte Parameter[*]Kompatibilitätsmodus für reine Brainfuck-Programme[/list]
[b]0.0.0[/b] - Kompatibilität[list][*] Jetzt werden auch verschachtelte Schleifen unterstützt[*]Kompatibilitätsmodi für 7, 8, 16 und 32 Bit[*]Gibt Errorlevels zurück (bisher undokumentiert)[*]verbesserte Fehlerbehandlung[*]...[/list][b]<kannte keine Versionsnummer>[/b]
Erste Veröffentlichung

Gruß
FAlter

[edit] Mein 1000. gezählter Beitrag! Ist ja passend dass ich genau da mit einer neuen Programmiersprache ankomme. [/edit]

[himitsu]

Und da behauptet man, ich habe Lange Weile.

So, jetzt fehlt noch der Schritt 2 > einen HQ9+fuck-Interpreter geschrieben in HQ9+fuck

[add]

Zitat:

SetLength(Memory, MP + 65536); //einfach mal 64 KiB dazu reservieren

65536 * SizeOf(Memory[0]) sind aber keine 64 KiB

Delphi-Quellcode:

...
Counter := 1;
case Source[IP] of
  '[': inc(Counter);
  ']': dec(Counter);
end;
...

Und sicher, daß Counter:=1; dort jeweils an der richtigen Stelle steht?

[himitsu]

Danke du A.....llerliebster DP-User,

wegen dir konnte ich gestern Abend nicht einschlafen.

Diese komischen zwei arschlangsamen Memos (memory und instructions) werden noch ersetzt (man sieht es nicht, aber dahinter liegt schon was "Schöneres", bzw. es war schon vor den Memos dort, aber ich hatte noch keine Zeit den Code dafür zu schreiben)

PS: Wenn ich das Richtig gesehn hatte, dann wird bei Brainfuck für den "Memory" per Standard nur je ein Byte verwendet ... einige BF-Programme laufen nicht mehr richtig, wenn der Überlauf bei dem Byte fehlt.

bei mit:
- field size = die Speichergröße in Byes der einzelnen Felder
- bitfield = simuliert z.B. bei x2 eine Word-"field size" (2 Byte) in einer 1-Byte-Umgebung
(bei Simulierung mit größeren Bitfeldern weiß ich noch nicht ob es richtig rechnet, drumm isses dort deaktiviert)

Und keine Sorge, wenn ich den Code irgendwann mal etwas aufgeräumt hab, geb ich auch gern diesen zur Einsicht frei,
obwohl dieses Teil nur Brainf**k kann und auch nur in 32-Bit-Windows-Delphi vorliegt.
(k.A., aber könnte auch sein, daß Freepascal damit zurechtkommt)


PS: Ich wollte dich schon fragen, warum deine Dateien hq9pf und [add]nicht[/add] hq9bf (HQ9-BrainFuck) heißen.

[himitsu]

Ich würde dir mal was empfehlen.
Wie schon gesagt, sind die "Standard"-BF-Interpreter 8-bitig.

In dem Anhang steckt unter anderem auch noch dein Win32-Interpreter (hq9pf.exe).

An den Beispielen wirst du aber sehn, daß besser wäre, wenn du eventuell die Speichergröße einstellbar machen würdest.
z.B. über einen Parameter nach dem Dateinamen, wo man 8, 16 oder 32 Bit aussuchen könnte.
(8 als Standard, wenn kein Parameter angegeben ist)

Ist auch nicht schwer, du brauchst ja einfach nur nach dem Inc/Dec einer Speicherzelle
bei 8 Bit ein "and $FF" und bei 16 Bit ein "and $FFFF" auf die veränderte Speicherzelle anwenden.


im Anhang:
Hello World die BF-Version
99 Bottles, ebenso in BF
Fibonacci - was da für Werte rauskommen, da wird selbst Delphi neidisch
Game of Life - erinnert mich zwar mehr an Bingo oder TicTacToe ... hauptsache der Source ist hübsch
Mandelbrot - ja, hier wird ein kleines Mandelbrotbildchen errechnet
Pi (16 bit) - errechnet die ersten 10 Stellen von PI
in einem 8 Bit-Interpreter rechnet es falsch
bei einem 16 Bit-Interpreter wird richtig gerechnet
bei einem 32 Bit-Interpreter rechnet es soooo lange, da will bestimm keiner auf die erste Zahl warten
Sierpinski Triangle - nichts Weltbewegendes, aber schaut euch mal Code und Ergebnis an,
also das Nenn ich mal 'nen wunderhübschen Quellcode
und dann gibt's noch jede Menge Batchfiles, welche jeweils FAlters Interpreter starten.

[add]
hier mal der Quellcode des Sierpinski-Dreiecks:

Code:

[ This program prints Sierpinski triangle on 80-column display. ]
                                >    
                               + +    
                              +   +    
                             [ < + +    
                            +       +    
                           + +     + +    
                          >   -   ]   >    
                         + + + + + + + +    
                        [               >    
                       + +             + +    
                      <   -           ]   >    
                     > + + >         > > + >    
                    >       >       +       <    
                   < <     < <     < <     < <    
                  <   [   -   [   -   >   +   <    
                 ] > [ - < + > > > . < < ] > > >    
                [                               [    
               - >                             + +    
              +   +                           +   +    
             + + [ >                         + + + +    
            <       -                       ]       >    
           . <     < [                     - >     + <    
          ]   +   >   [                   -   >   +   +    
         + + + + + + + +                 < < + > ] > . [    
        -               ]               >               ]    
       ] +             < <             < [             - [    
      -   >           +   <           ]   +           >   [    
     - < + >         > > - [         - > + <         ] + + >    
    [       -       <       -       >       ]       <       <    
   < ]     < <     < <     ] +     + +     + +     + +     + +    
  +   .   +   +   +   .   [   -   ]   <   ]   +   +   +   +   +    
 * * * * * M a d e * B y : * N Y Y R I K K I * 2 0 0 2 * * * * *

[FAlter]

Hi,

das Kommentar mit den 64 KiB hab ich entsprechend angepasst...

Der Parameter ist keine schlechte Idee, aber ohne Parameter sollte es der Interpreter-Standard sein und nicht immer auf 8 runter.

Der Counter könnte prinzipiell auch vor das Repeat kommen... das hätte den Vorteil, das dann auch verschachtelte Schleifen unterstützt werden und der ganze Code in der Schleife nicht mehr ganz unnütz ist.

hq9pf(uck) weil Klassen usw. kein + im Name haben dürfen.

Die Beispiele guck ich mir mal an.

Gruß
FAlter

[himitsu]

Zitat von FAlter:

Der Parameter ist keine schlechte Idee, aber ohne Parameter sollte es der Interpreter-Standard sein und nicht immer auf 8 runter.

Nja, Hauptsache man kann dann z.B. auch 8-Bit-Programme in 8 Bit laufen lassen.

Einige Programmierer nutzen eben den Überlauf geziehlt aus und wenn da der Überlauf an falscher Stelle erfollte ... nja, dann läuft es halt nimmer richtig.

Zitat von FAlter:

hq9pf(uck) weil Klassen usw. kein + im Name haben dürfen.

Wurde mir dann auch irgendwann klar.
Anfangs dachte ich bei hq9pf nur an "HQ9 BrainFuck".

Zitat von FAlter:

Der Counter könnte prinzipiell auch vor das Repeat kommen... das hätte den Vorteil, das dann auch verschachtelte Schleifen unterstützt werden und der ganze Code in der Schleife nicht mehr ganz unnütz ist.

Es sit genau andersrum.

Hier wird Counter immer wieder auf 1 gesetzt
und demnach sind keine verschachtelten [] möglich.

Delphi-Quellcode:

repeat
  inc(IP);
  if IP > Length(Source) then exit;
  Counter := 1;
  case Source[IP] of
    '[': inc(Counter);
    ']': dec(Counter);
  end;
until (Counter = 0);

So wird Counter am Anfang einmal initialisiert
und danach arbeiten nur noch Inc und Dec mit dem Counter.

Delphi-Quellcode:

Counter := 1;
repeat
  inc(IP);
  if IP > Length(Source) then exit;
  case Source[IP] of
    '[': inc(Counter);
    ']': dec(Counter);
  end;
until (Counter = 0);

[FAlter]

Hi,

Zitat von FAlter:

Der Counter könnte prinzipiell auch vor das Repeat kommen... das hätte den Vorteil, das dann auch verschachtelte Schleifen unterstützt werden und der ganze Code in der Schleife nicht mehr ganz unnütz ist.

Doch, genau so wie ich es geschrieben habe. Ich wollte es nur als neues Feature verkaufen und nicht als öden Bugfix.

Gruß
FAlter

[himitsu]

Ohh, dann hab ich mich glatt verlesen.

Joar, soein Feature wäre schon cool.


[edit]
bevor du meine schöne GUI beneidest ... dafür rechnet dein Interpreter bestimmt viel schneller und läuft auch noch fast überall.

[Daniel]

Mit solchen Themen-Titeln kommt dieses Forum noch in Verruf.
s. Anhang

[FAlter]

Zitat von Daniel:

Mit solchen Themen-Titeln kommt dieses Forum noch in Verruf.

Ja, und damit das auch funktioniert muss ich jetzt pushen.

Wie dem auch sein, ich war faul. Daher gibts in der neuen Version mal ganz unsauber programmiert die Parameter -7 -8 -16 unbd -32 die irgendwie die Größe der Werte begrenzen und ich mache sogar Verwendung von der Tabu-Anweisung halt.

Und demnächst werde ich vielleicht, durch RLE Komprimierung angeregt, einen optimierenden Bytecode-Compiler und dafür einen Bytecode-Interpreter schreiben. Dann sollten multiple +-<> Anweisungen schneller ausgeführt werden.

Anhang im ersten Beitrag ist aktualisiert.

Gruß
FAlter

[edit] Das Mandelbrot-Programm sieht echt schick aus. [/edit]