noch'n BF Interpreter

[FAlter]

Hi,

also die ReadKey aus FPC (Unit Crt) hat folgende Probleme:
1. wenn die Standardeingabe umgeleitet wird (z. B. von Datei) passiert nichts / wartet Programm entlos auf Eingabe
2. umgeht sie auch KeyMapping und gibt daher ggf. falsche Zeichen zurück

Delphi-Quellcode:

// initialisieren
H  := GetStdHandle(STD_INPUT_HANDLE);
FlushConsoleInputBuffer(H);

Das mit dem Flush gefällt mir bzgl. Standardeingabe umleiten auch nicht da ich vermute, dass dann was verloren gehen könnte...
Es soll ja auch möglich sein mit BF Dateien zu verarbeiten.

Abgesehen davon das der Code nur unter Windows läuft wird er sicher auch nicht besser sein:

Delphi-Quellcode:

// abfragen
CI.EventType := KEY_EVENT;
Repeat
Until ReadConsoleInput(H, CI, 1, Cardinal(i)) and (i = 1)
  and (CI.Event.KeyEvent.bKeyDown) and (CI.Event.KeyEvent.AsciiChar <> #0);
M[MP] := CI.Event.KeyEvent.AsciiChar;

KEY_EVENT? Gibts bei Standardeingabe umleiten auch nicht, oder?

FlushConsoleInputBuffer(H); Und noch ein Flush?
Also werden zweimal von Stdin eingelesene Daten weggeworfen?

Ich werde folgendes machen:
- wenn kein Parameter angegeben wurde wird read(Result) verwendet
- wenn der Parameter .key angegeben wu8rde wird Result := ReadKey verwendet

Damit erreiche ich Kompatibilität zu solchen Programmen während die Möglichkeit der Umlenkung der Standardeingabe nicht verloren geht.

Letzteres hat aber einen Haken: BF kennt keinen Befehl um das Ende der Datei abzufragen. Die nach stdin umgeleitete Datei muss also selbst sagen wo sie zu Ende ist...

[edit] Hab gerade festgestellt, das das Standardeingabe-umleiten auch mit read nicht zufriedenstellend funktionitert... hm, das ist aber komisch. Da hätte ich es eigentlich funktionierend erwartet... [/edit]

Gruß
FAlter

[himitsu]

Hab zwar noch keine Funktion gefunden, welche prüft, ob umgeleitet wurde, aber FlushConsoleInputBuffer funktioniert bei einer Datei nicht, also würden da auch keine Zeichen verloren gehn,
allerdings funktioniert ReadConsoleInput auch nicht und er ließt keine Zeichen ein = Endlosschleife.

Jedenfalls scheint dieses nun in beiden Fällen zu laufen.

Delphi-Quellcode:

var H: THandle;
  CI: TInputRecord;
  isRedirected: Boolean;
  i: Integer;
  C: Char;

begin
  // initialisieren
  H  := GetStdHandle(STD_INPUT_HANDLE);
  isRedirected := not FlushConsoleInputBuffer(H);

  while true do begin

    // abfragen
    if isRedirected then begin
      if EOF then begin
        {dateiende erreicht}
        //C := #0;
        break;
      end else Read(C);
    end else begin
      CI.EventType := KEY_EVENT;
      repeat
      until ReadConsoleInput(H, CI, 1, Cardinal(i)) and (i = 1)
        and (CI.Event.KeyEvent.bKeyDown) and (CI.Event.KeyEvent.AsciiChar <> #0);
      C := CI.Event.KeyEvent.AsciiChar;
      FlushConsoleInputBuffer(H);
    end;

    write(C);
    sleep(50);

  end;

Hier wird mal mit Break abgebrochen, aber dem BF-Programm übergebe ich eine #0, welche dann das Dateiende signalisiert.

Allerdings dachte ich immer Read ließt nur das ein, welches man verlangt und ohne ein Enter zu fordern, so wie es auch bei einer Dateieingabe geschieht
und nur ReadLn verlangt das Enter.
Nja, hatte es aber auch noch nie so bei einer Konsoleneingabe verwendet.

[FAlter]

Nützt aber nichts bei *nix Systemen. Daher ist es nicht für meine Plattformunabhängige Lösung geeignet.
Aber wie gesagt bei Read funktiniert die Umleitung auch nicht sowie ich es mir wünsche.

[himitsu]

Und da beschwere sich mal wer, daß ich erst garnicht versuche Cross-Plattform zu arbeiten.

Ach ja, mein "BF to pacal.bf" ist nun lauffähig (in 8 Bit).
Es wandelt ein BF-Script in eine Pascal-DPR um.

OK, meine IFs in BF sind noch sehr sehr unoptimal.
Ist auch garnicht so einfach sowas in BF hinzubekommen.

Aber die Laufzeit des Konverterscripts hat ja nicht mit der Laufzeit des Ergebnisses zu tun
und ihr glaubt garnicht, wie schnell urplötzlich das "kleine" Mandelbrot-Programmchen sein kann.
Und das, obwohl noch nichtmal optimiert wird.
( also z.B. Inc(P) + Inc(P) = Inc(P, 2) usw. )

Witzig ist dabei, daß dieser Konverter nur mit 32 Byte und einem Pointer auskommt
und wenn man unbedingt wöllte, dann würden auch 4 Byte plus den Zeiger ausreichen.
Also, obwohl es nicht grade sehr optimal arbeitet, bis ich doch recht zufrieden damit ... ist ja immerhin mein erstes richtiges BF-Programm.

In meinem BF-Interpreter kann aber jetzt eine derartige Optimierung aktiviert werden
und auch Strg+(Shift)+G, bzw. +B entfernen jetzt nicht nur Text/Kommentare und faßt alles zusammen,
sondern es entfernt jetzt auch offensichtlich unnötige BF-Befehle.
( z.B. >>< zu > )

dieses fibonacci.bf

Code:

++++++++++>>+>>+
[
    [
        +++++[<++++++++>-]<.
        >++++++[<-------->-]
        +<<<
    ]<.>>>>
    [
        -<[<+>>+<-]
        <[>+<-[>+<-[>+<-[>+<-[>+<-
            [>+<-[>+<-[>+<-[>+<-
            [>[-]>>+>>[-]+<<<<<-
            [>+<-]]]]]]]]]]]
        >>[<<+>>-]
        +>>>
    ]<<<
]

sieht in Delphi dann so aus

Delphi-Quellcode:

program mybf;

{$apptype console}

var
  m: array[0..1000000] of char;
  p: integer;

begin
  p := 0;
  inc(m[p]);
  inc(m[p]);
  inc(m[p]);
  inc(m[p]);
  inc(m[p]);
  inc(m[p]);
  inc(m[p]);
  inc(m[p]);
  inc(m[p]);
  inc(m[p]);
  inc(p);
  inc(p);
  inc(m[p]);
  inc(p);
  inc(p);
  inc(m[p]);
  while m[p] <> #0 do begin
    while m[p] <> #0 do begin
      inc(m[p]);
      inc(m[p]);
      inc(m[p]);
      inc(m[p]);
      inc(m[p]);
      while m[p] <> #0 do begin
        dec(p);
        inc(m[p]);
        inc(m[p]);
        inc(m[p]);
        inc(m[p]);
        inc(m[p]);
        inc(m[p]);
        inc(m[p]);
        inc(m[p]);
        inc(p);
        dec(m[p]);
      end;
      dec(p);
      write(m[p]);
      inc(p);
      inc(m[p]);
      inc(m[p]);
      inc(m[p]);
      inc(m[p]);
      inc(m[p]);
      inc(m[p]);
      while m[p] <> #0 do begin
        dec(p);
        dec(m[p]);
        dec(m[p]);
        dec(m[p]);
        dec(m[p]);
        dec(m[p]);
        dec(m[p]);
        dec(m[p]);
        dec(m[p]);
        inc(p);
        dec(m[p]);
      end;
      inc(m[p]);
      dec(p);
      dec(p);
      dec(p);
    end;
    dec(p);
    write(m[p]);
    inc(p);
    inc(p);
    inc(p);
    inc(p);
    while m[p] <> #0 do begin
      dec(m[p]);
      dec(p);
      while m[p] <> #0 do begin
        dec(p);
        inc(m[p]);
        inc(p);
        inc(p);
        inc(m[p]);
        dec(p);
        dec(m[p]);
      end;
      dec(p);
      while m[p] <> #0 do begin
        inc(p);
        inc(m[p]);
        dec(p);
        dec(m[p]);
        while m[p] <> #0 do begin
          inc(p);
          inc(m[p]);
          dec(p);
          dec(m[p]);
          while m[p] <> #0 do begin
            inc(p);
            inc(m[p]);
            dec(p);
            dec(m[p]);
            while m[p] <> #0 do begin
              inc(p);
              inc(m[p]);
              dec(p);
              dec(m[p]);
              while m[p] <> #0 do begin
                inc(p);
                inc(m[p]);
                dec(p);
                dec(m[p]);
                while m[p] <> #0 do begin
                  inc(p);
                  inc(m[p]);
                  dec(p);
                  dec(m[p]);
                  while m[p] <> #0 do begin
                    inc(p);
                    inc(m[p]);
                    dec(p);
                    dec(m[p]);
                    while m[p] <> #0 do begin
                      inc(p);
                      inc(m[p]);
                      dec(p);
                      dec(m[p]);
                      while m[p] <> #0 do begin
                        inc(p);
                        inc(m[p]);
                        dec(p);
                        dec(m[p]);
                        while m[p] <> #0 do begin
                          inc(p);
                          while m[p] <> #0 do begin
                            dec(m[p]);
                          end;
                          inc(p);
                          inc(p);
                          inc(m[p]);
                          inc(p);
                          inc(p);
                          while m[p] <> #0 do begin
                            dec(m[p]);
                          end;
                          inc(m[p]);
                          dec(p);
                          dec(p);
                          dec(p);
                          dec(p);
                          dec(p);
                          dec(m[p]);
                          while m[p] <> #0 do begin
                            inc(p);
                            inc(m[p]);
                            dec(p);
                            dec(m[p]);
                          end;
                        end;
                      end;
                    end;
                  end;
                end;
              end;
            end;
          end;
        end;
      end;
      inc(p);
      inc(p);
      while m[p] <> #0 do begin
        dec(p);
        dec(p);
        inc(m[p]);
        inc(p);
        inc(p);
        dec(m[p]);
      end;
      inc(m[p]);
      inc(p);
      inc(p);
      inc(p);
    end;
    dec(p);
    dec(p);
    dec(p);
  end;
end.

Und es ist garnicht so einfach NUR mit diesen Variablen

Delphi-Quellcode:

var
  m: array[0..1000000] of char;
  p: integer;

und diesen Befehlen

Delphi-Quellcode:

{ > }  inc(p);
{ < }  dec(p);
{ + }  inc(m[p]);
{ - }  dec(m[p]);
{ . }  read(m[p]);
{ , }  write(m[p]);
{ [ }  while m[p] <> 0 do begin
{ ] }  end;

ein Programm hinzubekommen,

aber da es sich hier um eine turingfähiges Programm handelt,
sollten sich damit in endlicher Zeit (kann allso etwas länger dauern) ALLE möglichen Programme/Berechnungen bewerkstelligen lassen.

[himitsu]

Ein Debugger (wenn man es so nennen darf), ist jetzt mit drinnen.

Also schrittweises Durchsteppen der BF-Codes und Haltepunkte (im "run"-Modus) sind möglich.
- "Instruction" = wenn der die Abarbeitung grad/gleich diese Instruction ausführen will
- "Memory" = wenn diese Speicherstelle gleich verändert werden soll


@FAlter:
hab auch ein paar Interpreter-Testcodes gemopst, etwas aufbereitet und mit eingefügt (Verzeichnis "Tests")

Wobei der Testcode für die obere Speicherbegrenzung wohl nicht viel ausmacht, da wir ja eine dynamische Speicherverwaltung drin haben, aber schaden kann er dennoch nicht.