Unbekannten Compiler entdeckt

Es gibt 191 Antworten in diesem Thema, welches 31.082 mal aufgerufen wurde. Der letzte Beitrag (23. Mai 2024 um 20:54) ist von muffi.

  • Klar einfach zu bauen, aber ich verstehe noch nicht, was das Ding über 2 Stunden für die 129 Blocks rummacht und von 129 auf 210 Blocks aufbläht. Ich glaube, DAS ist die Kunst zu bauen :wink:

    Apropos, ich habe mit Dir, EgonOlsen71, ja eigentlich genau den Richtigen dabei... meinen Monolithen habe ich mit Deinem Mospeed auch schon mehrfach versucht, ich habe es bislang aber noch zu keinem erfolgreichen Ende gebracht. Als Erschaffer hast Du doch bestimmt kleinere Tricks auf Lager, wie man das Compilat vielleicht kleiner bringt? Ich habe so vieles schon versucht...

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Dann habe ich meinen Augen aber nicht getraut: gestartet, lief los. Bis dann am ersten Screen die Meldung kam "Taste für weiter" dauerte es doch recht lang. Also mal Run/Stop gedrückt - BREAK IN XXX. :hae: List eingegeben...: es ist das Basic-Programm - sogar noch mit allen REM-Zeilen!

    Das nicht unüblich. Viele BASIC-Compiler aus der Zeit waren selber in BASIC geschrieben, dann aber üblicherweise mit sich selber compiliert. Auf die Art hat man auch gleich einen umfassenden Test dafür.

    Ich glaube, ich habe mich nicht ganz deutlich ausgedrückt... ich redete vom Compilat! Das angebliche Compilat lässt sich mit RUN/STOP unterbrechen und ist dann ein ganz normales Basic-Listing mit allen REM-Zeilen! Wie gesagt, ich rede da von meinem Lieblings-Monolithen, Monopoly!

    Ich hab dein "test2out" mal durch nen Disassembler geschickt. print "hallo" liegt als Basic Code vor, der auch tatsächlich an den Basic Interpreter übergeben wird (und der dann auch RUN/STOP auswertet), während die äußere Schleife (10 ... :GOTO 10) zu Assembler optimiert wurde.

    Dass das Ding so groß ist, scheint vor allem daran zu liegen, dass über 2KB Library-Routinen reinkopiert wurden, die - auf den ersten Blick - nie ausgeführt werden.

    Die "Optimierung" eines solchen Systems wäre, dass das Ergebnisprogramm nicht jede Zeile linear im Basicprogramm sucht, sondern jeweils die richtige Startadresse geladen und die Zeile ausgeführt wird (wobei irgendwelche Sprünge "weg" vom Compiler abgefangen wurden, damit das Programm die Kontrolle vom Basic-Interpreter zurückbekommt), und dann die nächste Zeile (mit bekannter Adresse) geladen und angesprungen wird. Man spart sich also Teile des Basicinterpreters (und der lineare Scan ist bei großen Programmen tatsächlich nicht zu vernachlässigen)

    In dem Fall sollte das Basic-Listing etwas anders aussehen als das Original, insbesondere keine GOTOs und so weiter.

    Ich weiß nicht, ob _ich_ sowas einen Compiler nennen würde, aber das Ding scheint schon etwas zu tun, was prinzipiell einen Effekt haben dürfte.

    Projekte: micromse

    Fertig: C128 wieder aufbauen, Bitte melde dich an, um diesen Link zu sehen.

    Inaktiv 😴: Bitte melde dich an, um diesen Link zu sehen.

  • Bei dem BASS-Compiler ist auch Basic Code in dem Pass-Dateien enthalten. Wenn man eine dieser Datein lädt, dann ab $002b,$002c die Basic Offsetadresse anpasst,

    dann mittels Action Replay den OLD-Befehle ausführt, kann man den Basic sogar listen. Viele Zeilen identische Zeilennummern was auch sehr merkwürdig ist. Um mehr

    über den Compiler aussagen zu können, benötigt an unbedingt die Anleitung.

    Achja, ich habe wieder einen mir unbekannten Compiler gefunden. Den findet ihr im Anhang.:)

  • Ich hab dein "test2out" mal durch nen Disassembler geschickt. print "hallo" liegt als Basic Code vor, der auch tatsächlich an den Basic Interpreter übergeben wird (und der dann auch RUN/STOP auswertet), während die äußere Schleife (10 ... :GOTO 10) zu Assembler optimiert wurde.

    Dass das Ding so groß ist, scheint vor allem daran zu liegen, dass über 2KB Library-Routinen reinkopiert wurden, die - auf den ersten Blick - nie ausgeführt werden.

    Die "Optimierung" eines solchen Systems wäre, dass das Ergebnisprogramm nicht jede Zeile linear im Basicprogramm sucht, sondern jeweils die richtige Startadresse geladen und die Zeile ausgeführt wird (wobei irgendwelche Sprünge "weg" vom Compiler abgefangen wurden, damit das Programm die Kontrolle vom Basic-Interpreter zurückbekommt), und dann die nächste Zeile (mit bekannter Adresse) geladen und angesprungen wird. Man spart sich also Teile des Basicinterpreters (und der lineare Scan ist bei großen Programmen tatsächlich nicht zu vernachlässigen)

    In dem Fall sollte das Basic-Listing etwas anders aussehen als das Original, insbesondere keine GOTOs und so weiter.

    Ich weiß nicht, ob _ich_ sowas einen Compiler nennen würde, aber das Ding scheint schon etwas zu tun, was prinzipiell einen Effekt haben dürfte.

    Naja, von mir ist das test2out nicht... aber Deine Erkenntnisse sind ja durchaus interessant. Aus lauter Wut, dass im "Compilat" sogar REM-Zeilen sind, habe ich den Mist gestern wieder gelöscht :D Muss ich das Monopoly halt nochmal durch das Ding jagen, aber diesmal vielleicht eher im Emulator, sonst tut mir meine arme 1571 wieder so leid <3

    Wenn natürlich andauernd der Interpreter aufgerufen wird, dann habe ich eigentlich schon meine Probleme damit, das Ganze als P-Code zu bezeichnen.

    Umso mehr ich lese und darüber nachdenke, umso weniger kann ich nachvollziehen, wo die gigantische Laufzeiten herkommen. Auf der anderen Seite hat der Pass 1 ja SYS 2067 drin stehen - wird also vermutlich mit sich selber compiliert sein.

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Achja, ich habe wieder einen mir unbekannten Compiler gefunden. Den findet ihr im Anhang.:)

    Auch diesen Compiler kenne ich :thumbup: Der ist von der Commodore Disk 64/128 Ausgabe 25. Ich habe das Ding aber nie zum Laufen bekommen, bei mir erscheint nach dem Starten und 2x Taste drücken immer ?OUT OF MEMORY ERROR IN 8120. Mal sehen, ob Deine Version läuft...

    Die verwandte, ähnliche, englische Zeitschrift CDU (Commodore Disk User) hat auch einen Compiler veröffentlicht gehabt, der war so ein Zwischending aus Tiny-Compiler und richtiger Compiler. Den habe ich auch nicht weiter getestet, weil mein Lieblings-Monolith den Compiler beim Laden überschreibt:thumbdown: (steht ab $8000 im Speicher).

    Edit: nein, auch Deine Version des CD-Compilers ist nicht lauffähig.

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Na, dann hoffe ich mal, das der Compiler funktioniert. Das scheint damals gang und gäbe gewesen zu sein, schrott-tools zu coden.

    Die Besten Compiler waren immer noch die Austro-(Comp und Speed) gefolgt vom Basic-Boss. Anbei habe ich mal einige Anleitungen Hochgeladen.:)

  • Es gibt sehr sehr viele Compiler, das wird mir jetzt klar.


    Die Frage ist, ob man aus den gewonnenen Kenntnissen über Vor- und Nachteile nicht selbst einen eigenen Compiler bastelt, eine F64 Edition ... :)


    Was muss der können?

    Was sind die Ziele?

    Kompatibilität und Geschwindigkeit scheinen sich auszuschließen.

    Wollen wir ein schnelles BASIC oder wollen wir, dass der Compiler alles bestehende frisst.

    Alles Bestehende haben wir ja: Austro Compiler


    Mir schwebt eher etwas vor, das eine erweitertes v2 BASIC Syntax kann.

    Wenn man wirklich schnell werden will, muss man halt "speziell" in BASIC coden.

    Wie beim PETSpeed, also Real Zahlen meiden und möglichst alles in Integer machen zum Beispiel.


    Meine Vorstellungen gehen in die Richtung:

    • der Compiler läuft auf einem PC (weil da alles viel einfacher zu machen ist)
    • das Source File ist ein PRG (BASIC Text com C64) oder auch einfach ein normales Textfile
    • das Kompilat ist ein PRG File für einen C64
    • die erste Version wird erst Mal nur wenig können und dann erweitert werden


    Vorschläge für die erste Version:

    • optimierter P-Code für alle BASIC Befehle
    • REM Befehl werden ignoriert
    • GOTO und GOSUB ersetzen durch direkt Adressen
    • Integer Addition und Subtraktion direkt als Maschinencode
    • DATA Zeilen werden vorab übersetzt als Werte Tabellen

    Ich denke sowas wäre machbar.


    Den RUNTIME Code könnte man unterschiedlich, je nach Bedarf anders implementieren:

    • Runtime im Ziel PRG (Nachteil: Größe des Programm, Ladezeit)
    • Runtime extra laden, zum Beispiel im $C Bereich und unter dem BASIC / Kernal ROM
    • Runtime in ein Modul auslagern (Vorteil: keine Größenbegrenzung, kein Verlust von C64 RAM, kleine Ziel Programm Größe)

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

  • Diddl Du solltest Dir mal vertrauensvoll den MOSpeed von EgonOlsen71 ansehen :wink:

    Edit: Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Stephan Scheuer Ich hatte meinen Eintrag schon editiert, auch der CD-Compiler läuft nicht. Der startet ja noch nicht mal richtig.

    Und nochmal Stephan Scheuer Meiner Meinung nach ist der beste Compiler der Basic-Boss, die Austro-Compiler sind dafür die Kompatibelsten. Was aber immer wieder in der Diskussion durchrutscht, ist ein Compiler, der ebenfalls zu PET-Zeiten schon bekannt war und auch dessen Namen trägt: Petspeed! Den darf man nicht vergessen, denn schlecht ist der nicht!

    Irgendwie finde ich das geil, dass ich nicht der Einzige bin, der Compiler sammelt :thumbup:

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • ...REM Befehl werden ignoriert... Naja, es gibt auch eine bestimmte Sorte von Codern, bei denen die Sprünge wie GOTO oder GOSUB auf REM-Zeilen zeigen. Das muss der Compiler erkennen und ggf. ändern.

    Ein Compiler muss compilate erstellen, die auch ohne Basic-ROM funktionieren. Einzige rühmliche Ausnahme ist hier der Basic-Boss, bei dem man mittels Directive "REM@ (Pfundzeichen) ALLRAM"

    Dieses bewerkstelligen kann.

  • ...REM Befehl werden ignoriert... Naja, es gibt auch eine bestimmte Sorte von Codern, bei denen die Sprünge wie GOTO oder GOSUB auf REM-Zeilen zeigen. Das muss der Compiler erkennen und ggf. ändern.

    Naja, es kann nicht ALLES gehen das im Interpreter geht!

    Wenn man das macht, dann ist der Compiler nicht mehr effektiv.

    Ich sehe den Compiler als Vorteil für Neuentwicklungen.

    Und man muss halt als Programmierer etwas auf den Compiler zugehen.

    Die Stärken des Compiler im eigenen BASIC Code nützen und auskosten.

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

  • bei denen die Sprünge wie GOTO oder GOSUB auf REM-Zeilen zeigen. Das muss der Compiler erkennen und ggf. ändern.

    Ja das ist schon klar!

    Es muss jede Zeile angesprungen werden können!

    Aber ich halte es nicht für sinnvol, so wie ich es weiter oben gelesen habe, dass der kompilierte Code Remarks enthält ...

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

  • Dem muss ich widersprechen. Ich habe soeben das Spiel "Commercial Town" mit dem CD-Compiler erfolgreich compiliert.8)8)

  • Ein Compiler muss compilate erstellen, die auch ohne Basic-ROM funktionieren.

    Das wird so nie funktionieren.

    Die 8K wären sonst halt einfach im Runtime Pack mit dabei.

    Irgendwo muss man ja Code haben der Berechnungen macht und Real Zahlen unterstützt und natürlich Strings.


    Man muss auch unterscheiden zwischen

    • Compiler die reinen Maschinen Code ausgeben (reiner Compiler)
    • Compiler die mit P-Code arbeiten (Hybrid Compiler/Interpreter)

    Bei einer Maschine die nur 64K Speicher hat, halte ich einen reinen Compiler für Unsinn.

    Der Code wird einfach viel zu groß bei einer 8 Bit Maschine.

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

  • Ein Compiler muss compilate erstellen, die auch ohne Basic-ROM funktionieren. Einzige rühmliche Ausnahme ist hier der Basic-Boss, bei dem man mittels Directive "REM@ (Pfundzeichen) ALLRAM"

    Dieses bewerkstelligen kann.

    Hmm, ich bin mir nicht sicher, aber der Compiler, der dieser Anforderung noch am Nächsten kommt, dürfte der Basic128 sein (eigene Fließkomma-Routinen). Aber auch der wird vermutlich bei manchen Funktionen die entsprechenden Basic-Routinen aufrufen. Ich kann mir nicht vorstellen, dass Abacus/Data Becker damals das Rom komplett selbst implementiert hat. Und das trifft auch auf den Boss zu, auch der nutzt (Basic-)Rom-Routinen. In dem Fall ist ALLRAM allerdings hinderlich, weil er auch Zeit verbrät, weil er ständig zwischen Rom und Ram hin- und herschalten muss. In meinem Benchmark-Test kann man das ganz gut erkennen, dass alle Cevi-Compiler das Rom nutzen, der Laufzeitunterschied beim Cosinus-Test ist ja absolut nur marginär.

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Ist zwar ein wenig OT, aber vielleicht hilft es hier ...

    Ich habe in meinen Fundus eine mal kopierte Anleitung des TINY-Basic-Compiler für VC-20 und C-64 gleichzeitig, auf deutsch, Die eigentliche Software stammt von Abacus Software, wurde meine ich dann auf deutsch von DATA Becker verkauft (?). Vielleicht fehlt oder hilft das ja weiter ...

  • Das bedeutet, dass jeder seinen Compiler in den höchsten Tönen lobt und auch mal das Eine oder Andere weg lässt oder etwas übertreibt.

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

    Hast du schon den Post Bitte melde dich an, um diesen Link zu sehen. von mir gelesen?


    Ich habe gerade mal den Runtime Code vom CD-Compiler angesehen. Dazu ein dreifaches Buuuhh. Das ist ein klassischer Fall von Softwareklau und sich mit den Lorbeeren anderer schmücken.

    Der CD-Compiler ist ein leicht abgeänderter Austro-Speed Compiler. Das scheint früher wohl auch normal gewsen zu seine, die Software anderer zu klauen und under seinem Label zu veröffentlichen.

  • Ist zwar ein wenig OT, aber vielleicht hilft es hier ...

    Ich habe in meinen Fundus eine mal kopierte Anleitung des TINY-Basic-Compiler für VC-20 und C-64 gleichzeitig, auf deutsch, Die eigentliche Software stammt von Abacus Software, wurde meine ich dann auf deutsch von DATA Becker verkauft (?). Vielleicht fehlt oder hilft das ja weiter ...

    Na dann stell es doch mal rein :wink:

    Hört sich tatsächlich mal nach einem Compiler an, den ich noch nicht kenne :cursing:

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Diddl Du solltest Dir mal vertrauensvoll den MOSpeed von EgonOlsen71 ansehen :wink:

    Edit: Bitte melde dich an, um diesen Link zu sehen.

    Oja das scheint wirklich sehr cool zu sein, dieser MOSspeed.

    Muss ich mir mal ganz genau angucken!

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

  • @Bitte melde dich an, um diesen Link zu sehen.

    Hast du schon den Post Bitte melde dich an, um diesen Link zu sehen. von mir gelesen?

    Äh, nein, bzw. jetzt ja. Wie hast Du das geschafft? Ich bekomme immer nur das, und dabei ist es egal, ob es der Vice ist oder echte 8 Bit:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Einfach den CD-Compiler und Commercial Town auf ein d64 kopiert, den Namen "Commercial Town" auf "Town" gekürzt und den Anweisungen gefolgt.

    PS Ich habe im Post Bitte melde dich an, um diesen Link zu sehen. noch was zum CD-Compiler geschrieben und den TINY-Compiler hochgeladen.

    Das Compilat von Commercial Town gibt es im Post Bitte melde dich an, um diesen Link zu sehen. zum runterladen.