BASIC-Compiler im Quelltext?

Es gibt 69 Antworten in diesem Thema, welches 9.966 mal aufgerufen wurde. Der letzte Beitrag (24. April 2023 um 19:17) ist von 1570.

  • Wenn ich das BASIC frei erweitern kann, dann wäre es schon genial.

    Schade, dass das SYS so kaputt war bzw. es kein sauberes SYSadresse,parameter,parameter gibt (mit Call By Reference bitte, damit man auch Werte zurückgeben kann und das überhaupt schnell ist). Das hätte ja schon gereicht und wäre auch Compiler-freundlich, im Gegensatz zu dem "Assemblercode muss weitere Parameter über Interpreter-Aufrufe holen", was man so typischerweise machen muss.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ich wette, dass der als nativer Code nochmal Größenordnungen schneller kompilieren würde

    Ich habe in den letzten Wochen etwas an Blitz! gebastelt und einen (sehr eingeschränkten) BASIC V2-nach-JavaScript-Transpiler geschrieben. Das Ergebnis bisher:

    Bitte melde dich an, um diesen Link zu sehen. - Blitz! im Browser: PRG im Browser auswählen, Klick, kompiliertes PRG herunterladen. Passiert alles Client-seitig, es gibt keine serverseitige Komponente, soll heißen, es wird nichts irgendwo hochgeladen.

    Das ist alles noch voll Beta, aber Gold Quest 6 kompiliert das schonmal korrekt - in 100 Millisekunden, dürfte also der derzeit schnellste BASIC V2-Compiler sein, was die Zeit fürs Kompilieren angeht. ;)

    Reblitz64 hat auch einige Beschränkungen von Blitz nicht mehr, z.B. darf der P-Code über $7FFF hinausreichen.

    Ich kenne fast alle P-Codes der Austro-Compiler auswendig

    Die Runtime von Blitz!/Austro habe ich kurz durch Bitte melde dich an, um diesen Link zu sehen. geschoben, bin aber noch nicht sonderlich weit und weiß auch nicht, ob ich mich weiter motivieren kann. Es wäre aber supercool, alle Teile von Blitz kommentiert/editierbar zu haben, u.a., weil man dann Ports auf andere Plattformen machen könnte (BASIC V2 kompilieren für z.B. den Bitte melde dich an, um diesen Link zu sehen. wäre schon klasse).

    Es wäre auch schick, direkte Unterstützung für z.B. Multiline-IF/THEN/ELSE/LOOP à la Bitte melde dich an, um diesen Link zu sehen. einzubauen. Bei WSB ist aber blöd, dass a) die Tokens mit drei Bytes Länge verschwenderisch sind, b) ein "Continue" fehlt und c) es keine petcat-Unterstützung für WSB gibt. Andere BASIC-Erweiterungen in der Richtung haben soweit ich bisher sagen kann noch kaputtere IF/THEN/ELSE-Implementierungen oder sind (für meinen Geschmack) insgesamt viel zu fett.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • ....Blitz nicht mehr, z.B. darf der P-Code über $7FFF hinausreichen....

    Das habe alle Austro Compiler. Light wohl an der Nutzung von 16Bit Adresswerten. +32768 und -32768.

  • Ja genau. Bei den Integer-Variablen für die Zeilennummern jongliert der Compiler noch mit +/- 32768 rum, bei den Offsets haben sie es sich gespart, vermutlich weil wenige BASIC-Programme länger als das werden. Gold Quest 6 kam da aber locker hin, und andere z.B. mithilfe von Paradoxon Basic geschriebenen Programme sicher auch. Glücklicherweise ist das nur eine Beschränkung des Compilers, nicht der Runtime.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Eine kleine Verständnisfrage zum Reblitz64:

    Auf github steht:

    • Removed: The :: mechanism to pass any code to the original BASIC interpreter got removed.

    Bedeutet das Extensions jeglicher Art brauchen die :: nicht mehr vor dem Befehl ? Oder werden Extensions nicht mehr vom Reblitz unterstützt ?

    Ich habe da ein paar Programme mit JiffyDOS Befehlen und den Plum's Extensions für C*BASE...

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Die sollten einfach so gehen, probier mal. Es gab nur eine Art "Escape"-Mechanismus, mit dem man z.B. per ::PRINT"HALLO" das PRINT des BASIC V2-Interpreters statt des Codes für PRINT in der Blitz-Runtime aufrufen konnte. War soweit ich weiß undokumentiert und sah nach Überbleibsel zum Debugging bei der Entwicklung von Blitz aus und sorgte dort für mächtig Spaghetticode.

    Nur bei BASIC-Erweiterungen, die Befehle "gehijackt" haben (z.B. VERIFY jetzt zum Malen von Kreisen benutzen oder so...) könnte das Wegfallen von :: ein Problem sein. Falls ich was übersehen habe, kann man das aber auch fix (und sauberer...) wieder hinzufügen.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Scheint zu funktionieren:

    Bitte melde dich an, um diesen Anhang zu sehen.

    d.h. die JiffyDOS Befehle sind kompiliert worden (siehe 2082: ).

    In PASS1 werden die Zeilen mit Syntax Error angemeckert.

    Original im BASIC Code sieht das so aus:

    39 ::*fi$prg:return

    40 ::*fi$seq:return

    41 ::*fi$rel:return

    42 ::*fi$usr:return

    Ich hab das aber noch nicht im BBS laufen lassen....

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Tja, Kompilieren oder Optimieren ?
    Ich optimiere meistens.
    z.B. Binäre Codes in den Anhang,
    Speicher löschen und kopieren mit SYS-Aufrufen.
    Zur Not tut es auch ein kleines Maschinen-Programm, daß man mit SYS aufruft.

    Schönen Gruß.

  • Scheint zu funktionieren

    Du kannst auch das Ergebnis-PRG binär mit dem Ergebnis des C64-Blitz!-Compilers vergleichen, die sollten komplett identisch sein.

    Falls da was nicht klappen sollte, gerne mit dem Source nochmal melden, dann schaue ich mir das an.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.