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. :lol:

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

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

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. :angel2:

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

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:

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". :oops:

Zitat:

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:

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. :oops:

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. :stupid:

[Daniel]

:roll:

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

[FAlter]

Zitat:

Zitat von Daniel

:roll:

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

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

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]

[himitsu]

ich laß grad seit 'ner Weile 'ne modifizierte Version des "kleinen" Mandelbrotbildchen berechnen :wall:
aber schon erstaunlich, was man mit 8 Bit alles hinbekommt

[FAlter]

Verdammt, warn mich doch for das das nicht HQ9+fuck kompatibel ist. In dem crazy code kommen 9en vor und ich krieg immer wieder 99 bottles of beer. Bin schon ganz :drunken: nicht dass ich gleich :kotz: muss.

Nun, habe jetzt die 9en durch (nine) ersdetzt... und probier es mal im 7 bit Modus laufen zu lassen.

Gruß
FAlter

[Mithrandir]

*hust* Freaks.. *hust*

:mrgreen:

[himitsu]

Tschuldschung ... vergiß die Hs und Qs nicht :stupid:

hab noch ein Bild oben angehägt
und das ist zumindestens ein 8-Bit-Code ... bin mal gespannt, was bei bei 7 rauskommt.

[FAlter]

Er rechnet immer noch...

[himitsu]

Hätte den PC heute Nacht (um besser schlafen zu können) nicht nur auf Sparflamme laufen lassen sollen,
aber wer konnte denn Ahnen, daß es so lange dauert. :shock:

Aber die Auflösung ist doch schon beachtlich und mit viel mehr Zeit, wäre noch etwas mehr möglich
und das nur mit ein paar 8-Bit-Berechnungen.

[add]
Und noch was genial Einfaches oder einfach Geniales?

[divBy0]

:wiejetzt:

BF und die Ausgabe in ein Image? Oder hab ich was falsch verstanden?

[Neutral General]

Zitat:

Zitat von divBy0

:wiejetzt:

BF und die Ausgabe in ein Image? Oder hab ich was falsch verstanden?

Soweit ich das verstanden habe, hat himitsu ein Programm geschrieben welches das Text-Mandelbrot in ein Bild-Mandelbrot konvertiert.. Bin mir aber nicht sicher.
Alternativ könnte man (oder ich habs falsch verstanden und es wird tatsächlich so gemacht) die Standard-Ausgabe auch in eine Datei umleiten und Pixel für Pixel schreiben. (Der Bitmap Header ist mal ein anderes Thema :mrgreen:)

[divBy0]

Aber das konvertieren dauert ja nicht so lange...

Oder es läuft ein BF Programm und die Ausgabe sind dann Pixel und werden in das Image gezeichnet.

[himitsu]

Also das BF-Programm erzeugt ein Bild in Form von Text (A-Z),
dazu hab ich mir ein Programm geschrieben (in Delphi), welches diesen Text in ein Bitmap übersetzt.
- A bis Z als Intensität und das Leerzeichen, bzw. alles Andere als ganz Schwarz.

Beitrag #11
> mandelbrot.txt = BF-Programm
> Mandelbrot - Text2Image.exe = der Converter

Der Converter ist auch nix Besonderes:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  SL: TStringList;
  i, i2: Integer;
  S: String;
begin             
  Memo1.Hide;  Button1.Hide;  CheckBox1.Hide;
  SL := TStringList.Create;
  SL.Text := Memo1.Text;
  i2 := 0;
  for i := SL.Count - 1 downto 0 do
    if Trim(SL[i]) = '' then SL.Delete(i)
    else i2 := Max(Length(Trim(SL[i])), i2);
  with Image1.Picture.Bitmap do begin
    Width := i2;
    Height := SL.Count * 2;
    Canvas.Brush.Color := clBlack;
    Canvas.FillRect(Rect(0, 0, Width, Height));
    for i := Height div 2 - 1 downto 0 do begin
      S := SL[i];
      for i2 := Width - 1 downto 0 do
        if (i2 < Length(S)) and (S[i2 + 1] in ['A'..'Z']) then begin
          Canvas.Pixels[i2, i * 2] := (Ord(S[i2 + 1]) - Ord('@')) * 255 div 26 * $010101;
          Canvas.Pixels[i2, i * 2 + 1] := Canvas.Pixels[i2, i * 2];
        end;
    end;
    if CheckBox1.Checked then SaveToFile(ChangeFileExt(ParamStr(0), '.bmp'));
  end;
  SL.Free;
end;

Aber theoretisch wäre es möglich das Bitmap auch direkt in BF zu erzeugen und abzuspeichern.


Dieses BF-Programm erzeugt z.B. in der Standardausgabe ein Datei, welche man direkt als .COM abspeichern lassen sollte.
Diese .COM wiederrum ist ein 8-Bit-BF-Interpreter, mit welchem man ein BF-Programm "abspielen" kann.

Quasi das Henne-Ei-Problem, denn was war nun zuerst da?
> das BF-Programm, welches die .COM erzeugt
> oder die .COM, welche das BF-Programm verarbeiten kann



Aber Einiges kann ich schonmal sagen:
- ein BF-Programm zu schreiben ist relativ leicht, wenn man einmal verstanden hat, wie's geht
- dabei hilfreich ist auch der geringe Sprachumfang, von nur 6 Befehlen
- aber die Speicherverwaltung ist ein Akt
- man muß sich genau überlegen was man wie wo ablegt, um
> möglichst geringe Wege und und damit auch wenig/übersichtlichen Code zu erzeugen

Ein kleiner Fehler am Anfang (z.B. eine Variable/Speicherstelle vergessen und schon darf man womöglich das halbe Programm umschreiben. :wall:

Also ich kann es jedem nur empfehlen ... man lernt ganz neue Denkweisen, welche bestimmt auch in Delphi gut anzuwenden sind.

[FAlter]

Das langsame Teil rechnet immer noch. Derweil arbeite ich an einer optimierten Version, welche tatsächlich schneller zu sein scheint. Genauer gesagt, sie wandelt den BF code in eine andere Darstellung um und nimmt dabei Optimierungen vor.

Aber lange dauerts auch mit der alten (langsamen) Variante auch nicht mehr :-)

[himitsu]

Ich fahr dann auch mal heim ... bin mal gespannt, wie weit meiner mit Rechnen ist.

hab mal alles zusammengepackt, was ich grad so mithab

[FAlter]

Hi,

die vor etwa einer Stunde angekündigte optimierte Version ist da!

Was sit tut? Den code optimieren und dabei in eine interne Darstellung ünberführen, die dann von einem erneuereten Interpreter viel schneller interpretiert wird.

Gerade bei der mandelbrot-Berechnung macht sich das deutlich bemerkbar.

Der erste Beitrag ist (natürlich samt Anhang) aktualisiert.

Gruß
FAlter

[divBy0]

Wann kommt den von euch die erste Inline-BF-Version für Delphi??? :mrgreen:

[himitsu]

hier das Ergebnis: man sollte besser nicht auf die Zeit ganz unten im Text achten :shock:

@divBy0:
Du kannst doch FAlters Klasse verwenden?
Schau mal in seine Codes rein
und aus meinem MiniBF läßt sich auch leicht eine Funktion basteln. :zwinker:

[FAlter]

Hi,

ich habe mich dem Tastatur-Problem (siehe Thread von himis Programm) angenommen. Letztendlich war ich weder mit read(Char) noch mit ReadKey zufrieden, weshalb ich beide genommen habe und man per Parameter -key umswitchen kann wenn ein Programm unerwartet auf Eingaben reagiert.

Hoffe mal das jetzt noch mehr BF Programme laufen... Für die Kompatibilität dienen jetzt schon die -8 (bzw. -7 bzw. -16 bzw. -32), -bf und -key Switches.

Vielleicht weise ich auch mal auf die undokumentierten Switches hin:
-v (verbose) schreibt zusätzliche Infos raus
--norun führt das Programm nciht aus, tut aber alle anderen Schritte (nur in Kombination mit -v sinnvoll)
--nostrip lässt den Vorgang des Kommentar-entfernens weg (was auch immer das bringen soll)

Gruß
FAlter

[himitsu]

Zitat:

Zitat von Daniel (Beitrag 990776)

:roll:

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

Nach über 5 Jahren immernoch auf Platz ein.
Also das soll uns mal jemand nach machen.