Hallo,

ich hatte in letzter Zeit einige Probleme mit dem Quelltext. Da der Compiler in den Anfangszeiten dazu
gedacht war, nach Assembler zu kompilieren und ich mir nicht die Mühe gemacht habe, den Compiler direkt
nach dem Umstieg auf C umzuschreiben, habe ich versucht alles so gut wie möglich zurechtzupfuschen...
Mit mäßigem Erfolg.
Nun gibt es mehrere Probleme:

• Es sind ungenutze Funktionen drinnen, die nur auf andere Funktionen umleiten (Abwärtskompatiblität)
  
• Der rekursive Baum, der beim kompilieren aufgebaut wird, ist immernoch an die Assemblersyntax angepasst.
  
• Es wurde in den verschiedenen Funktionen immer wieder das Dateihandle manipuliert durch Aufrufe von Pos und Seek - diese sollen nun komplett durch Rekursion ersetzt werden, da sie sehr zur Unübersichtlichkeit beitragen.
  
• (das schlimmste!) Der rekursive Baum wird nicht aufgelöst! Das Programm wird einfach abgebrochen und der Programmfluss wird unterbrochen - eine Qual für den Leser. Das Hauptprogramm ruft eine Funktion Main auf, die program aufruft, die prolog aufruft ...

Daher habe ich mich entschlossen das ganze neuzuschreiben; eine Taktik die ich oft verwende - ist der
Code nichts mehr Wert -> neuschreiben (natürlich vorher den alten sichern - man kann ja Ideen übernehmen) und
genau das habe ich vor...

Diesmal wird von den Stützpfeilern aus begonnen. Ich habe auch schon (theoretisch) ein System, das Funktionen
mit optionalen Parametern nach C konvertieren kann. Implementiert sind auch schon Variablendeklarationen und
Konstantendeklarationen - Funktionsdeklarationen sind gerade dabei, geschrieben zu werden.

diesmal muss es einfach klappen


mfg Thunder

Hallo,

Ich habe eine längere Pause gemacht(in der ich mich kein bisschen mit BlueBasic beschäftigt habe),
weil ich in letzter Zeit ein bisschen Streß mit der Schule hatte.
Daher muss ich mich jetzt wieder ein bisschen in den Code einarbeiten, aber da ich den Code schön in
Includes aufgeteilt habe sollte das kein Problem sein.
Große Neuerungen habe ich nicht zu verkünden, weswegen die Versionsnummer nicht angehoben wird.
Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Bis jetzt sind Stringvergleiche allerdings auf statische Strings beschränkt. Das heißt, dass in der If
keine Manipulation des Strings erlaubt ist. Also gibt es insgesamt 4 Möglichkeiten Strings auf Gleichheit
zu überprüfen:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Local string1$,string2$
If "Hallo"="Irgendwas" Then Print "1"
If "Hallo"=string1 Then Print "2"
If string1="Hallo" Then Print "3"
If string1=string2 Then Print "4"

Input kann bis jetzt nur einen komplett-statischen String übernehmen, d.h. irgendein Ausdruck der zwischen
Anführungszeichen steht. Werde ich hoffentlich noch verbessern.
Der Anlass für diesen Eintrag ist allerdings eher dieser Screen:



Bis zum nächsten Mal,

Thunder

... hoffentlich nicht zu oft.

Hallo,

Möglicherweise ist schon am Titel erkennbar, dass ich den Matheparser neugeschrieben habe. Es gab beim alten
ein schweres Problem mit der Rekursion, weil der Matheparser manchmal Klammern geschlossen hat, die noch von
anderen Teilen des Compilers verwendet worden wären, gab es manchmal Fehler und manchmal nicht.
Daher habe ich zum ersten Mal von Strg+A + Backspace Gebrauch gemacht und das ganze neugeschrieben. Ich glaube
er ist ein bisschen kürzer und funktioniert jetzt, soweit ich das beurteilen kann.

Winkelfunktionen (Sin, Cos, Tan, ASin, ACos, ATan) funktionieren jetzt! An dieser Stelle Danke an D2006, der
mich darauf hingewiesen hat, dass ich die Grad in Radianten umrechnen muss.

Auch bei Strings gibt es einige Probleme. Sie funktionieren zwar, aber ich bin mir nicht sicher, ob BlueBasic
mit BlitzBasic in Sachen Stringmanipulation(nämlich Geschwindigkeit) mithalten kann. Denn vor jeder Operation,
die mit dem String durchgeführt werden soll, muss überprüft werden, ob dieser schon initialisiert wurde. Außerdem
muss der String, bevor er manipuliert wird, in einen Puffer kopiert werden, falls er sich selbst im String-Ausdruck
verwendet. Dh:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Local s$=" programmiere "
s="Ich"+s+"BlueBasic"

Das wird sich herausstellen, wenn ich Millisecs() implementiert habe ...

Changelog
Code: [AUSKLAPPEN] [EINKLAPPEN]

Hier stand so lange kein String-Beispiel mehr. Da muss ein neues her!
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Global s$="Hallo Welt!"
Print s
s=s+" und Hallo Mond!"
Print s
s="Hallo Natur! "+s
Print s
End

In der nächsten Zeit möchte ich Funktionen mit optionalen Parametern versehen, da ich das komplett vergessen habe.
Da C das nicht kann, werde ich es in den Compiler integrieren müssen.
Eingefallen ist mir das erst, als ich Funktionen wie Mid und Instr in die String-Lib einbauen wollte.


Bis zum nächsten Mal,

Thunder

Hallo,

In der letzten Zeit habe ich weniger Zeit mit BlueBasic verbracht, allerdings ist mir ein ganz guter Gedanke
gekommen: Ich habe eine Funktion eingeführt, mit der man C-Funktionen in den BlueBasic-Code importieren kann. So
kann ich verschiedene Funktionen (Stringfunktionen, Mathefunktionen, ...) auslagern. Das ganze funktioniert so:
Man kann .h-Dateien, die im Verzeichnis lib\ des Compilers liegen mit dem Befehl ";import dateiname_ohne_endung"
importieren. Wenn in dieser Datei bestimmte Funktionen durch die erweiternde C-Funktion //BBIMPORT markiert werden,
können diese auch mit BlueBasic verwendet werden. Einfaches Beispiel mit der "math.h":
math.h
Code: [AUSKLAPPEN] [EINKLAPPEN]
zugehöriger, möglicher BlueBasic-Code:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

;import math
Global x%
For x=-10 To 10 Step 2 
	Print "Zahl: "+x+"   Abs: "+Abs(x)
Next
;Waitkey ;Für BlitzBasic
End

Durch die Kommentarzeichen bleiben die Codes kompatibel .

Probleme gibt es zur Zeit mit den Winkelfunktionen Sinus und Cosinus. BlueBasic liefert andere Werte als
BlitzBasic. Folgender Beispielcode(Blue- bzw BlitzBasic):
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

;import math
Global x%=61
Print Sin(x)
Print Cos(x)
;Waitkey; Für BlitzBasic, damit es nicht gleich beendet
End

BlitzBasic-Ausgabe
Code: [AUSKLAPPEN] [EINKLAPPEN]
BlueBasic-Ausgabe
Code: [AUSKLAPPEN] [EINKLAPPEN]

Es sind afaik beide Werte richtig, da afaik bei den Winkelfunktionen 2 Lösungen herauskommen können.
Komischerweise hat ein einfaches ersetzen von (C-Funktion) cos(x) durch cos(360-x) nicht funktioniert.
Ich werde sehen, wie ich das in den Griff bekomme. Falls es jemand weiß, wäre ich froh über eine erläuternde
PN/einen erläuternden Kommentar. Wir haben Winkelfunktionen erst seit kurzem in Mathematik.

Auf die Frage, worauf ich in dem Worklog hier eingehen soll, habe ich leider keine Antworten bekommen.
Bis nächstes Mal überlege ich mir selber was


mfg Thunder

Hallo,

Ich habe mir diesmal erlaubt die Versionsnummer gleich um 2 (also von 0.00.16 auf 0.00.18) heraufzusetzen, da in der letzten
Zeit ziemlich viel passiert ist und der Changelog sehr groß ist.
Zuerst: Ich habe nun Multi-Vergleiche in Select-Case eingebaut. Etwas wie "Case 1,2,3" ist nun möglich indem ein Select-Case-Default-Konstrukt (BlueBasic) in ein if-else if-else-Konstrukt in C umgewandelt wird. Jetzt fehlt bei Select nur noch folgendes Konstrukt:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Select True
Case x>=5 And x<=10
End Select

Als nächstes habe ich Strings eingebaut. Das ging in C ganz leicht und wenn ich jetzt nicht durch die wunderschöne Ausführung des Beispielprogramms getäuscht wurde, sollte alles funktionieren. Die Tests laufen aber noch ...

Float habe ich jetzt meiner Meinung nach ausreichend getestet - Es sollte funktionieren.

Und die kleineren Änderungen im Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Erklärung zur Umwandlung von Befehlen durch den Compiler
Es gibt Befehle, die direkt durch den Compiler in C-Syntax umgewandelt werden. Dazu gehören die grundlegenden Befehle (If, Function ...), einige kleine Funktionen (Chr, ...) und ganz wenige große (Print/Write). Ich möchte nun auf die Befehle eingehen, die nicht durch den Compiler umgesetzt sind:

Diese Befehle habe ich in C-Syntax in die Datei blue.h programmiert, die mit dem Compiler mitgeliefert werden soll. Das allererste was der Compiler in jede Datei schreibt ist: >>#include "...PFAD.../blue.h"<<. So werden diese Funktionen importiert.
Im Moment sind folgende Funktionen darin:
Code: [AUSKLAPPEN] [EINKLAPPEN]
integer_input, float_input und string_input werden die jeweiligen Input-Funktionen für alle 3 Datentypen, die in BlueBasic/BlitzBasic unter einer Funktion(Input) vereint sind. Der Compiler wird anhand des Ausdrucks entscheiden, welche Funktion einzusetzen ist.
preparestring wird aufgerufen, wenn ein String in der Größe verändert wird. Vorher tat das realloc, allerdings ist mir aufgefallen, dass es passieren kann, dass mit realloc plötzlich ein anderer String aus dem Arbeitsspeicher seinen Weg in den vom Benutzer definierten String findet. So erhielt ich einmal folgende Ausgabe:
Code: [AUSKLAPPEN] [EINKLAPPEN]
Daher wurde eine Funktion (preparestring) notwendig, die darauf achtet, dass der unbenutzte Teil des Strings geleert wird.
string_assign wird noch nicht verwendet, soll allerdings später Int-Variablen in Strings umwandeln.
input_write ist die Funktion, die jede Input-Funktion aufruft. Sie ist dafür zuständig, dass der String der der Input-Funktion übergeben wurde ausgegeben wird.

Jetzt habe ich noch eine Frage an meine Leser (falls vorhanden ): Soll ich in späteren Worklogs auch auf Umformungen des Compilers oder seine Struktur eingehen? Oder auf etwas anderes? Wenn ihr Interesse habt, die nächsten Beiträge in diesem Worklog in ihrem Inhalt zu beeinflussen, schreibt mir bitte in die Kommentare oder per PN.


Bis zum nächsten Mal,

Thunder

Hallo,

Ich habe jetzt alles so gut wie möglich wieder auf Standard gebracht. Vorher habe ich zwar in
meinem Eintrag geschrieben, dass alles wiederhergestellt ist, aber ich konnte nicht ahnen, dass
sich noch so viele Bugs verstecken (sind nicht alle im Changelog aufgeführt).

Also - da ich jetzt mit den grundlegenden Sprachkonstrukten (Mathematik, Abfragen, Schleifen)
fertig bin, habe ich ein Programm geschrieben, das die Kompatiblität zwischen BlitzBasic und
BlueBasic ermittelt. Beide haben den Test bestanden:

BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Global ergebnis%
Local x=20,y=43,z=50

ergebnis=20 And 50 + 20 Or 50 + 20 Xor 50 ; Sollte 116 sein
If x=20 And (Not y<>43) And ((z>49 And z<51) Or z=50) Then
	; Diese Zeile ist zum Teil inkompatibel - In BlueBasic sind die Klammern um "Not y<>43" nicht
	; notwendig - in BlitzBasic schon!
	ergebnis=ergebnis+1
EndIf
If ergebnis<>117 Then Print "Fehler in Mathe-Parser":End

If ergebnis>117 Then
	Print "Fehler in IF"
	End
Else If ergebnis<=116 Then
	Print "Fehler in IF"
	End
Else If ergebnis=117 Then
	ergebnis=ergebnis+2
Else
	Print "Fehler in IF"
	End
End If

Select ergebnis
Case 0
	Print "Fehler in SELECT"
Case 200
	Print "Fehler in SELECT"
Default
	ergebnis=ergebnis+1
End Select

If ergebnis<>120 Then Print "Irgendwie hat sich das Ergebnis durchgeschummelt!"

While ergebnis<200
	ergebnis=ergebnis+2
Wend

If ergebnis<>200 Then Print "Fehler in WHILE"

Repeat
	ergebnis=ergebnis-10
Until ergebnis<=50

If ergebnis<>50 Then Print "Fehler in UNTIL"

For ergebnis=0 To 100 Step 50
Next

If ergebnis<>150 Then  ;If und Else in einer Zeile funktioniert noch nicht.
	Print "Fehler in FOR"
Else
	Print "Test bestanden!"
End If

(Das Programm testet Schleifen, Mathe-Parser und Abfragen.)

Changelog!
Code: [AUSKLAPPEN] [EINKLAPPEN]

Nahe Zukunft
Ich freu mich schon. Strings sind nämlich auch schon teilweise implementiert. Die habe ich immer
nebenbei eingebaut und an einem wirklich kleinen Beispiel getestet. Ich rechne allerdings damit,
dass ich Strings in C in den Griff kriege. Floats sollten eigentlich jetzt schon funktionieren -
ich habe sie nur noch nie getestet. BlueBasic-Float == C-Float. Lässt sich allerdings durch meinen Aufbau im Compiler mit nur einem Handgriff auf C-Double ändern, falls notwendig.

Etwas ferner sehe ich da noch die Types und Dims und Blue-Arrays (Blitz-Array). Types könnten
etwas problematisch werden: C-struct != BlitzBasic-Type.

Und da es gerade aktuell ist wünsche ich dem BlitzBasic-Portal hier nochmal Alles Gute zum vierten Geburtstag!


Bis zum nächsten Eintrag,

Thunder

Hallo,

Sehr erfreuliche Nachrichten habe ich mit diesem Eintrag zu verkünden. Gerade jetzt in etwa 15 Minuten
ist es mir gelungen aus allen Matheparsern, die ich bis jetzt für dieses Projekt geschrieben habe (es
waren 3) einen zusammenzuschrauben, der funktioniert!

Es funktionieren wieder alle Programme, die keine Strings und Types verwenden

--
Durch mein Zweitprojekt, das ich parallel zu BlueBasic entwickle (ThunderOS) wurde ich etwas in der Entwicklung
von BlueBasic aufgehalten, da mir gerade ein ziemlich enormer Schritt gelungen ist, der ThunderOS stark verbessert hat.
--

Leider gibt es in C ein Problem, das es in Assembler nicht gab: printf macht zur Zeit noch Probleme. Da
ich schon länger versuche sie zu behandeln, werde ich das nicht mehr heute tun (Müdigkeit+Programmieren+Ich = Mist).

Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]


mfg Thunder

Hallo,

Der Worklog ist ja bei den ganzen neuen Worklogs (von denen ich einige sehr gut finde) beinahe untergegangen.

Nein - Es sind leider noch nicht alle Fehler behoben. Es hat sich aber eigentlich viel getan. Changelog!
Code: [AUSKLAPPEN] [EINKLAPPEN]

Leider gibt es einen Fehler, der mich weiterhin nicht in Ruhe lässt. Dieser steckt im Matheparser und
es kommt bei folgendem Code:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Function Sgn(x)
	Return (x<0)*-1 Or (x>0)
End Function

zu diesem Problem:
Code: [AUSKLAPPEN] [EINKLAPPEN]
(ich meine nicht das unnötige return 0; )

Es sieht so aus als würde der Matheparser, der für Assembler noch sehr gut funktioniert hat - überhaupt
nicht zu C umbaubar zu sein, daher werde ich ihn bald neu schreiben.

Allerdings ist es mir durch die obigen Bugbehebungen gelungen ein Programm, das ich früher schon Mal gepostet
habe (um auf das Syntaxhighlighting der GUI aufmerksam zu machen), wieder zum Laufen zu bringen:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Global x,y,op,ergebnis	;Variablen

Print "Taschenrechnerprogramm."
Print
Print "Operatoren:"		;Informationen
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	;Ein paar Kommentare um das Highlighting anzumerken
	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

Achja, noch ein positiver Aspekt der Portierung auf C, der mir noch gar nicht aufgefallen ist, ist, dass der Code
nun auf JEDEN Fall (ich verwende keine Windows-Funktionen) plattformunabhängig bleibt und da ich zum kompilieren
gcc aus MinGW verwende, sollte der Code auch mit jeder gcc-Version der verschiedenen Betriebssysteme(Linux, Unix, ...)
kompatibel sein.

Bis zum nächsten Mal,

Thunder

Hallo,

Ich habe schlechte Neuigkeiten. Gestern kurz bevor ich eingeschlafen bin, habe ich alles nochmal
von vorne durchgedacht. Möglicherweise hätte ich den Compiler zu Ende bringen können, aber, da
ich ihn fertig machen will brauche ich eine erhöhte Sicherheit. Deswegen habe ich den Compiler
temporär umgeschrieben, damit er nach C und nicht nach Assembler kompiliert.
Es gibt noch einige Fehler in der Implementation, weil ich bei der Überarbeitung des gesamten Compilers
nicht die Möglichkeit zum Zwischenkompilieren hatte
(Umschreiben bestimmter Funktionen führte dazu, dass andere nicht mehr funktionierten...)

Ein Beispiel aus der Frühzeit des Compilers konnte ich schon kompilieren:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Function Sgn(x)
	Return (x<0)*-1 Or (x>0)
End Function

Local z%
For z=-20 To 20
	Print z+" sgn("+z+"): "+Sgn(z)
Next
End

Ich bin zur Zeit sehr damit beschäftigt alle Beispieldateien, die ich seit dem Anfang des Compilers
geschrieben habe, zum Laufen zu bringen. Deswegen kann ich mich nicht sehr um Optimierungen des
Codes kümmern. Obiges Beispiel erzeugt folgenden C-Code:

Code: [AUSKLAPPEN] [EINKLAPPEN]
return 0; wird automatisch angehängt. Ein End-Befehl erzeugt aber auch ein return 0; (nur in
der main()-Funktion / ansonsten exit() - an der Stelle Danke an Noobody für den Hinweis).
Auch alle anderen Funktionen bekommen automatisch ein return zugewiesen, da gcc meckert, wenn es
keines gibt (bei nicht-void-Funktionen) und man in BlitzBasic keinen Rückgabewert angeben muss.

Bis jetzt war das vielleicht noch keine schlechte Neuigkeit - das steckt aber im Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]

Bis zum nächsten Mal (wahrscheinlich funktionieren bis dahin die wichtigsten Funktionen wieder),

Thunder

Edit: Der ursprünglich geplante Titel: "H"+"al"+"lo "+"We"+"lt!"
ging sich nicht aus.

Hallo,

Ich habe jetzt wieder die Strings hineingenommen und sie funktionieren schon so weit,
dass sie einen Worklogeintrag verdienen. Die Strings sind bisher nur auf globale Variablen beschränkt,
doch das wird nicht schwer zu ändern sein, da Strings nur Zeiger auf Zeichenketten sind und daher
immer nur 4 Bytes an Speicher brauchen (die Zeiger). Ich habe auch herausgefunden, wieso das Stringsystem letztes
Mal nicht funktioniert hat:
Immer, wenn eine Stringzuweisung passiert ist habe ich den jeweiligen String zwischengespeichert. Dazu
habe ich eine Kopierroutine verwendet, die den Zeiger auf den String überschrieben hat und daher sah ich am
Ende nur lustige Smilies in der Eingabeaufforderung.
Um zu demonstrieren wie gut die Strings schon funktionieren, hier ein funktionierendes Beispiel:
BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Const x$="lo "
Global s$="al"+x+"We"
s="H"+s+"lt!"
Global s2$=s
s="Kompiliert mit dem BlueBasic-Compiler "+0+"."+00+"."+12
Print s2
Print s

Ausgabe
Code: [AUSKLAPPEN] [EINKLAPPEN]

Möglicherweise ist es störend, dass eine Doppelnull im String wirklich zu einer Doppelnull wird, aber das
könnte ich beheben. Das ist eine Aufgabe von 30 Sekunden. Falls es mir nicht mehr gefällt mache ich das.

Hier der ziemlich kleine Changelog:
Code: [AUSKLAPPEN] [EINKLAPPEN]


An Types habe ich nicht weitergearbeitet. Ich war zu überwältigt davon, dass die Strings jetzt gehorchen.
Ich werde nun das Feature implementieren, dass Strings variabler Länge zulässt. Bisher sind sie auf 4095
Zeichen beschränkt, wie es beim vorletzten Worklogeintrag auch war.

In letzter Zeit habe ich mir auch einige Gedanken über "Toleranz des Compilers" gemacht. Ich glaube, meiner
wird, besonders aus programmiertechnischen Gründen, nicht so tolerant wie der BlitzBasic-Compiler (besonders
bezüglich automatischer Typumwandlung).


mfg Thunder