Der Standardweg ist/war eher, die (wenigen) wirklich zeitkritischen Routinen direkt in Assembler zu schreiben und dann per SYS aufzurufen. Deswegen unterstütz(t)en viele Umgebungen damals auch Inline-Assembler (siehe Turbo Pascal oder auch Vision Basic). Zwischen gut handoptimierten Assembler und aus Basic generiertem M-Code liegen dann doch nochmal ein paar Faktoren, jedenfalls solange nicht z.B. bei MOSpeed eine der Optimierungsregeln greift. (in Richtung Code-Optimierung muss man einen Blick auf llvm-mos behalten - das hat aber leider mit Basic nichts am Hut)
Hallo Besucher, der Thread wurde 6,4k mal aufgerufen und enthält 56 Antworten
letzter Beitrag von muffi am
MOSCloud - ein Remote-BASIC-Compiler für das WiC64
- EgonOlsen71
- Erledigt
-
-
Deswegen unterstütz(t)en viele Umgebungen damals auch Inline-Assembler (siehe Turbo Pascal oder auch Vision Basic).
Ein Assembler ist ohnehin drin in MOSpeed. Ich könnte den auch Inline nutzbar machen. Per Default abgeschaltet würde mich das nicht weiter jucken. Würde etwa so aussehen, also völlig banane...
Zugriff auf Variablen und BASIC-Zeilennummern ginge wohl auch. Will sowas jemand benutzen (die Frage ist ernst gemeint, nicht rhetorisch...
)? -
Naja, im Vision Basic-Thread nebenan wird ziemlich genau sowas gemacht. Ist halt nicht mehr "BASIC V2" (weil das Produkt dann vom BASIC V2-Interpreter ausgeführt was anderes/nichts Sinnvolles mehr macht), aber man deckt damit den Anwendungsfall "irgendein kleines Detail im Programm muss richtig schnell sein" ab (z.B. die Ausgabe einer Karte auf dem Bildschirm etc.).
Für Gold Quest wäre das auch schick gewesen, aber wohl nur im Zusammenhang mit einem P-Code-Generator (wegen Code-Größe). Andere Baustelle...
-
Ich fände das ziemlich interesannt, als leichten Einstieg in C64 assembler, aber das ist sich echt mir spielerrei bei mir
-
Ist halt nicht mehr "BASIC V2" (weil das Produkt dann vom BASIC V2-Interpreter ausgeführt was anderes/nichts Sinnvolles mehr macht)...
Zur Not könnte man beide Implementierungen einbauen und per Inline Assembler das BASIC umgehen. Pustet den Code natürlich weiter auf, aber wenn das kein Faktor ist, dann ginge sowas:
...aber schön ist anders...
-
Oder man macht's als Vorverarbeitung: Ein Tool, das die ASM-Zeilen erkennt, in einen separaten Bereich kompiliert und die REM (asm)-Zeilen dann durch entsprechende SYS ersetzt. Crank the PRINT macht das so (nur nicht für Asm sondern zum Beschleunigen von Print). Vorteil ist dann, dass das ein eigener Verarbeitungsschritt und nicht an den BASIC-Compiler gebunden ist und auch im Interpreter läuft. Nachteil ist, dass Vorverarbeitungsschritte nerven (aber bei längeren Programmen kommt man eh nicht drumherum, es sei denn, man will z.B. auf Kommentare verzichten).
Hm. Da fällt mir auf, dass man eigentlich eine Menge Convenience per Vorverarbeitung machen könnte inkl. IF/THEN/ELSE und Loops...
Edit: Achnee, geht schon, ist aber Murks. Bei CtP war das sinnvoll, weil das nur eine Optimierung macht und der Originalcode auch läuft, aber "Vorverarbeitung nötig" (wenn die nicht auch auf dem C64 stattfinden kann) führt über kurz oder lang dazu, dass man eigentlich besser ein LLVM-Backend für Basic V2 geschrieben hätte. Auch cool, aber...
-
Oder man macht's als Vorverarbeitung: Ein Tool, das die ASM-Zeilen erkennt, in einen separaten Bereich kompiliert und die REM (asm)-Zeilen dann durch entsprechende SYS ersetzt.
Aber damit würde der direkte Zugriff auf die Variablen des compilierten Programms sowie das direkte Anspringen von Zeilennummern entfallen, denn das würde, von BASIC aus versucht, nicht funktionieren.
-
Zugriff auf die Variablen geht nicht? Also bei Blitz! geht das, weil das Layout der Variablen im Speicher (ob kompiliert oder nicht) gleich ist. Soll heißen, wenn man das Programm mit z.B. DIMA% anfängt, ist die erste Variable in VARTAB auch A%, sowohl kompiliert als auch unkompiliert. Ist das bei MOSpeed anders?
GOTO raus aus ASM-Teilen ist wohl verzichtbar (wenn auch praktisch für das in #45 beschriebe).
-
Blitz! ist da voll kompatibel zu BASIC V2, wie es sich gehört (scnr
)Ja, das ist so oder so alles etwas hässlich. BASIC hat einfach keine brauchbare Schnittstelle zu Assembler (siehe auch BASIC-Compiler im Quelltext? ). USR() ist ein schlechter Witz.
-
Blitz! ist da voll kompatibel zu BASIC V2, wie es sich gehört (scnr
)War ja klar...
Das Speicherlayout im Vergleich zu BASIC war (und ist) mir tatsächlich völlig hupe und von daher ist es auch ziemlich anders.
-
Das war ja fix! Cool!
ldx i%! lädt (nur) das Low-Byte von i%, oder?
-
Das war ja fix! Cool!
ldx i%! lädt (nur) das Low-Byte von i%, oder?
Ja. Du kannst aber auch
machen, um das Highbyte zu laden.
-
Zwei Fragen an EgonOlsen71
1. Betrifft das "nur" die Moscloud oder auch den Mospeed?
2. Wäre es für Lower/Higher Byte nicht besser, die Syntax gängiger Assembler zu nehmen, also #< und #>?
-
Zwei Fragen an EgonOlsen71
1. Betrifft das "nur" die Moscloud oder auch den Mospeed?
2. Wäre es für Lower/Higher Byte nicht besser, die Syntax gängiger Assembler zu nehmen, also #< und #>?
Ja, das geht auch mit der Kommandozeilenversion. Ist ja die gleiche Codebasis. Ist per Default aber auch aus...steht im Wiki, wie man das aktiviert.
Bei der Syntax verwechselst du was. Du kannst auch #< und #> machen, aber das lädt dir nicht den Inhalt der Variablen, sondern Low- und Highbyte der Adresse. Hier willst du aber den Inhalt an der Adresse von i% laden (also quasi den Inhalt der Variablen), nicht einen Zeiger auf die Variable.
-
EgonOlsen71 Ah, ok, danke für die Info! War oben wohl dann etwas missverständlich ausgedrückt. Ich hatte dabei nicht bedacht, dass wir ja im Compiler-Umfeld sind, da gibt es natürlich Variablen. Als Assembler-Kundiger streiche ich geistig meist das Wort Variablen aus dem Geist, wenn es um Assembler geht... da gibts nur Speicherinhalte
