BlueBasic Compiler

Kommentare anzeigen Worklog abonnieren
Gehe zu Seite Zurück  1, 2, 3

Worklogs BlueBasic Compiler

Strings raus, Types rein

Mittwoch, 31. März 2010 von Thunder
Hallo,

Ich habe mir jetzt Mal lange Zeit gelassen. Das größte Problem war Motivationslosigkeit, da die Strings
einfach nicht funktionieren wollten. Also habe ich das Hauptübel, die Strings, aus dem Code gelöscht.
Der Compiler kann jetzt wieder nichts mit Strings variabler Länge (Mit Const deklarieren funktioniert) anfangen.

Stattdessen habe ich nun mit Types angefangen. Die Deklaration durch Type funktioniert bereits. Bis auf die
"geheimen" Type-Elemente (die Zeiger, die auf das nächste bzw. das Element vor dem aktuellen zeigen) funktionieren
sie für Integer-Variablen. Mit der Initialisierung habe ich nun aber ein kleines Problem. Ich überstürzte das ganze
und am Ende vergaß ich dabei, wie man in BB Types deklariert. In BlueBasic geht das bis jetzt OHNE den New Operator.
Allerdings nur, weil ich vergessen habe. Das wird in der nächsten Version behoben.

Große Fortschritte hat auch die IDE gemacht. Diese arbeitet jetzt mit bluecc.exe zusammen und erkennt automatisch,
wenn ein Programm nicht kompiliert werden konnte.

Changelog:
Code: [AUSKLAPPEN]
|--
   Versionsnummer: 0.00.10
   
   o True bekommt wieder den Wert 1 anstatt von 0xFFFFFFFF

   o Problem mit Variablen- und Konstantennamen gelöst. Variablennamen und
     Konstantennamen, die Assemblerbefehlen gleichen sind nun zulässig!
   
   + BlueIDE: hat eine Funktion dazubekommen, die sie erkennen lässt, wenn
     der Compiler einen Fehlerbericht ausgegeben hat und benachrichtigt den Benutzer.
    
   + BlueIDE: Funktion der F1-Taste vorläufig hinzugefügt. Wenn der Cursor vor, hinter
     oder innerhalb eines Befehls steht und F1 gedrückt wird, wird der Befehlsname in
     einer Messagebox angezeigt - Später soll eine Hilfe-Datei zu dem Befehl geöffnet werden.
    
   Versionsnummer: 0.00.11
   
   o Variablenpraefix-Bug beseitigt. Info:
     Der Bug hat dazu geführt, dass der Compiler manchmal abstürzte, da der Variablenpräfix '_'
     noch nicht in jeder Funktion bekannt war.   
   
   - Alle Funktionen und Codeabschnitte, die mit Strings zu tun hatten, wurden entfernt.
   
   + Types wurden zum Teil implementiert.
   
   o Verschiedenste Bugs gefixt.
--|


Was kommt bald?

  • Fertigstellung der Types für Integer
  • Blitz-Arrays bzw. Blue-Arrays


Die 2 Punkte sollten machbar sein und bevor ich mich wieder auf die Strings stürze, werde ich mir
dazu irgendwas zum Lesen suchen. Einfach drauf los programmieren hat nicht funktioniert.


Screen (man beachte die Größe im Arbeitsspeicher): https://www.blitzforum.de/upload/file.php?id=8267


mfg Thunder

Strings in Entwicklung

Montag, 22. März 2010 von Thunder
Hallo,

Ich bin in der letzten Zeit damit beschäftigt Strings zum laufen zu bringen. Folgendes zu den Strings:
Zur Zeit sind es nicht wirklich Strings, denn es wird ihnen zwar mit malloc() Speicher bereitgestellt, doch
dieser bleibt im Moment noch konstant (4095 Bytes). Einiges will noch nicht so funktionieren, wie ich das
will, aber folgendes Beispiel lässt sich schon kompilieren und ausführen:

BlitzBasic: [AUSKLAPPEN]
Const x$="lo "
Global s$="Hal"+x+"We"
s=s+"lt!"
Print s


Falls sich jetzt einer fragt: Wieso genau 4095 Bytes? Das ist doch Verschwendung!
Eigentlich stimmt das nicht ganz, da das Betriebssystem (in diesem Fall Windows) den Arbeitsspeicher in
Stücke von 4096 Bytes unterteilt. Egal wie wenig Speicher ich von malloc() anfordere - Betriebssystemintern
bleibt der Rest, der bei der Division durch 4096 entsteht unnutzbar. Daher ist der kleinste Speicherbereich
den man allokieren kann 4096 Bytes. Ich nehme 4095 zur Sicherheit Very Happy

Was hat sich sonst so getan? Hier der Changelog:
Code: [AUSKLAPPEN]
   o Änderung der Ebenen des Matheparsers. Diese sehen nun so aus:
      0) Klammern
      1) *  /
      2) +  -
      3) <  >  =  <>  >=  <=
      4) Not
      5) And
      6) Or Xor
      
   o Wert von True angepasst. Statt 1 wird nun 0xFFFFFFFF verwendet

   + Globale Strings kommen nun hinzu. Tests laufen.
   
   + Automatische Erstellung eines Fehlerberichts, falls sich das Programm in
     einer Schleife aufhängt. Es wird ein Fehlerbericht ausgegeben, der mir
     anzeigt in welcher Funktion der Fehler mit welchen Parametern passiert ist.
    
   o Problem mit Funktionsnamen gelöst. Funktionsnamen, die Assemblerbefehlen
     entsprechen konnten früher nicht verwendet werden. Jetzt ist das Problem
     durch das Präfix '_' gelungen. Präfix ist bei Variablen noch ausständig.


Ideen für später
  • Möglichkeit Funktionen als Inline zu deklarieren. Das stelle ich mir etwa so vor:
    BlitzBasic: [AUSKLAPPEN]
    Function:Inline Add(x,y)
    Return x+y
    End Function

    Es würde nicht die Funktion deklariert werden, sondern einfach der Code der Funktion an die
    Stelle eingesetzt werden, an der die Funktion aufgerufen wird. Das würde die generierte
    EXE-Datei zwar größer machen (nicht sonderlich), aber bei sehr vielen Funktionsaufrufen auch
    schneller sein. (Muss ich mir noch überlegen, da es nicht kompatibel zu BlitzBasic ist)
  • (Super-)Strict-Modus (wie in BlitzMax)


Übrigens, da ich das letztes Mal gar nicht betont habe: Wenn ich zum Grafikteil komme, dann
wird dieser mit an Sicherheit grenzender Wahrscheinlichkeit mit OpenGL umgesetzt, außer ich
scheitere daran den Compiler linuxfähig zu halten.

Anmerkung zu Stringkonstanten in Programmen, wie sie zB hier verwendet werden:
BlitzBasic: [AUSKLAPPEN]
x=5 ; (ich weiß, blödes Beispiel)
If x=5 Then Print "X ist ein Element der natürlichen Zahlen"
If x=7 Then Print "X ist ein Element der natürlichen Zahlen"
If x=9 Then Print "X ist ein Element der natürlichen Zahlen"

Hier ist es so, dass der Assembler den String "X ist ein Element der natürlichen Zahlen" 3 Mal in die
Assemblerdatei packt. Das sind insgesamt 120 Bytes. In so einem Fall sollte man lieber eine Konstante
mit Const deklarieren (oder auch eine Variable, wenn sie dann funktionieren), die den String enthält.


mfg Thunder


Edit: Ich habe das Projekt jetzt in BlueBasic umbenannt. An dieser Stelle möchte ich mich nochmal bei Smily bedanken, der mich auf diese juristische Unsicherheit hingewiesen hat.

Ein neuer BlitzBasic Compiler?

Montag, 15. März 2010 von Thunder
Hallo,

Hier ist der Worklog zu meinem BlueBasic-Compiler. Dieser soll BlueBasic-Code nach Assembler
kompilieren können. Den Compiler programmiere ich in BlitzMax.
Ich möchte im ersten Eintrag kurz den Stand der Dinge, meine Ziele und ein paar Sachen erwähnen.

Mein Ziel ist es einen Compiler zu schreiben, der im Großen und Ganzen ziemlich streng kompatibel
zum BlitzBasic-Compiler der 2D-Version sein soll, die nicht mehr offiziell vertrieben wird.
Das ist das höchste Ziel. (BlueBasic soll also kompatibel zu BlitzBasic werden)

Zur Zeit steht alles so:

(Codeboxen um Platz zu sparen)
Code: [AUSKLAPPEN]
Bedingungen:
   - If ElseIf Else      funktioniert 100%
   - Select Case Default   funktioniert 100%

Schleifen:
   - For To Next         funktioniert 100%
   - While Wend         funktioniert 100%
   - Repeat Until         sollte funktionieren (noch nicht getestet)
   - Repeat Forever      funktioniert 100%

Datentypen:
   - Int               funktioniert 100%
   - String            0%
   - Float               0%
   - Array               0%
   - Type               0%
   
Mathematik:
   Implementiert sind: <arithmetische Operationen: +  -  *  /> 
                  <logische Operationen: And  Or  Xor  Not>
                  <Vergleichsoperationen als boolische Werte:  <  >  =  <>  >=  <=  >
                  <boolische Konstanten: True (1), False (0)>
                  <Klammern>
   o) ein kleiner Fehler in / ist bekannt. Dieser lässt das Programm abstürzen.
   
Funktionen:
   - Funktionen an sich   funktioniert( manches ist falsch implementiert ) 75%
      - Zusatzfeature zu Funktionen (keine Ahnung ob BB das auch erlaubt): Die Funktionen dürfen
        ÜBERALL im Code stehen, außer in Funktionen.
   - lokale Variablen      funktioniert 100%
   

Sonstiges:
   - Labels (für die Verwendung mit Goto und Gosub)
   - Goto
   - Gosub
   - Print
   - Input (für Ganzzahlen)
   - Exit
   - Return
   - End
   
nicht BlitzBasic-Standard:
   - Inline-Assembler mit dem Befehl Asm und anschließendem String
   - Continue (springt zum Schleifenbeginn - hat mir immer gefehlt in BB :D)


Im Moment wird alles für Windows kompiliert in das PE-Format. Außerdem werden IO-Operationen zur Zeit
über die Konsole erledigt. (ich versuche dennoch alles Linuxfähig zu halten)
Es ist durchaus möglich, dass ich gar nicht zum Grafikteil komme, aber ich möchte so weit kommen, wie
es (für mich) geht und hoffe, dass die Eröffnung dieses Worklogs nicht umsonst war.

--
Zum Matheparser möchte ich noch folgendes erwähnen: Ich weiß nicht ganz genau, wieviele Ebenen BlitzBasic
zum Parsen der mathematischen Ausdrücke verwendet. Ich habe zur Zeit 6 Ebenen:

0) Klammern
1) * / > < = <> >= <=
2) Not
3) + -
4) And
5) Or Xor

Diese Reihenfolge wird noch geändert.
--

Zusätzlich programmiere ich noch eine kleine IDE, die uA kleingeschriebene Befehle in die richtige
Schreibweise konvertiert, da mein Compiler die Befehle nur erkennt, wenn sie richtig geschrieben sind.
(wird sich hoffentlich noch ändern)


Zum Schluss noch ein kleines Programm, dass sich mittlerweile auch kompilieren lässt:
BlitzBasic: [AUSKLAPPEN]
Global x,y,op,ergebnis

Print "Taschenrechnerprogramm."
Print
Print "Operatoren:"
Print "<1> Addition"
Print "<2> Subtraktion"
Print "<3> Multiplikation"
Print "<4> Division"
Print "<0> Beenden"
Print
Repeat
x=Input("Zahl 1 : ")
y=Input("Zahl 2 : ")
op=Input("Operator : ")
If op=0 Then Exit
Select op
Case 1
ergebnis=x+y
Case 2
ergebnis=x-y
Case 3
ergebnis=x*y
Case 4
If y=0 Then
Print "Durch 0 darf nicht dividiert werden!"
Print
Continue
Else
ergebnis=x/y
EndIf
End Select
Print "Ergebnis: "+ergebnis
Print
Forever


Übrigens sollte es nicht notwendig sein, Variablen vorher zu deklarieren, aber weil das eben
besserer Programmierstil ist und um die Funktionsfähigkeit zu gewährleisten, deklariere ich
die Variablen immer vor.

An diesem Beispiel kann man auch hervorragend veranschaulichen wie schön es sein kann eine
Continue-Funktion zu haben Wink.


Thunder

Edit: BlizBasic nun überall durch BlueBasic ersetzt.

Gehe zu Seite Zurück  1, 2, 3