Ich habe die Runtime vom Austro-Comp disassembliert, die Sprungtabelle am Ende Platziert und nach $C000 assembliert. Es kann auch jede andere Adresse genutzt werden.
Ich hatte mich die Tage über den Umgang von Blitz mit Konstanten etwas gewundert. Im Code konnte ich folgende Opcodes nicht finden (habe aber auch nicht lange gesucht):
Es ist ja auch die kürzere Austro-Comp Runtime. Die passt nach $C000-$CFFF, so dass der P-Code den Bereich von $0801-$1784 auch nutzen kann.
Müsste man mal schauen, was an der Austro-Speed-Runtime wie groß ist und ob man die irgendwie flexibel anpassbar bekommt. Ohne Fließkomma zum Beispiel wäre schon sehr nett. Das wäre evtl. in Reblitz64 sogar relativ einfach einzufügen (einfach in einem Pass alles durchgehen und Feature-Flags setzen, dann Runtime per ACME o.ä. mit entsprechenden Flags kompilieren).
Andersherum wäre auch eine Runtime schick, die ohne BASIC-ROM auskommt, dann könnte man $0801-$CFFF komplett für BASIC benutzen. Das könnte aber etwas Arbeit sein. 
und wenn man mal eben den Abstand zwischen zwei Punkten in 2D brauchte, hat man eh' Fünfe gerade sein lassen und statt a²+b²=c² einfach a+b=c genommen, das war meist gut genug
Alternative: überprüfen, wofür der Abstand überhaupt gebraucht wird und ggfs. die Rechnung so anpassen, dass man gleich mit c² statt c weiterrechnen kann.
Will man z.B. wissen, welches von N Objekten am nächsten ist, braucht man nicht unbedingt die Abstände vergleichen - man kann auch einfach die Quadrate der Abstände vergleichen, das funktioniert ebenfalls.
Oder: "Ist das Objekt näher als X Längeneinheiten?" -> "Ist das Quadrat der Entfernung kleiner als X*X?"
Ist compilierter Basic-Spaghetti-Code schneller als compilierter strukturierter Basic-Code?
Beispiel für Spaghetti-Code:
10 fori=1to10000:printi:nexti:end
Beispiel für strukturierten Basic-Code:
10 for i=1 to 10000
20 print i
30 next i
40 end
Gibt es da Unterschiede bei den einzelnen Compilern?
Nein, das Kompilat nutzt keine Zeilennummern mehr, sondern benutzt nur noch Speicherstellen. Das ist meine ich auch bei allen Compilern so.
Also zunächst mal kommt es auf den compiler an, ich habe längst nicht alle ausprobiert.
Du hast hoffentlich das gelesen https://www.c64-wiki.de/wiki/Compiler
und du willst eigentlich noch das lesen
https://www.idealine.info/emuecke/tipstricks/c64.htm
bevor du überhaupt an Compilen denkst.
Und wenn du das alles drauf hast, wirst du feststellen, dass du eigentlich Assembler lernen willst.
Huh also z.B. ein Haufen Spiele wurden in Basic geschrieben inkl. gerade Gold Quest 6. Das hätte in Assembler geschrieben in erster Linie (deutlich) länger zur Entstehung gebraucht und vermutlich kaum oder gar nicht davon profitiert.
Z.B. Pirates! wurde vermutlich auch nicht in Basic geschrieben, weil die Programmierer kein Assembler gekonnt hätten, oder z.B. auch der Blitz-Compiler an sich.
Wobei es natürlich ggf. angenehmere (kompilierbare) Hochsprachen als Basic gibt, auch auf dem C64.
Edit: Falls das so gemeint sein sollte, dass man so oder so AUCH Assembler (auf dem C64) können sollte - klar.
Vermeer wurde auch in Basic geschrieben und compiliert. Mir ist das bis vor 2 Jahren nicht aufgefallen.
Das ist meine ich auch bei allen Compilern so.
Naja, im Falle des BASS-Compilers bin ich mir da überhaupt nicht sicher 
bevor du überhaupt an Compilen denkst.
Wenn man sich über Compiler an sich informieren will, ist in der Informatik normalerweise das Drachenbuch eines oder sogar das Standardwerk. Und wenn man auf Drachen keinen Bock hat, gibt es da noch von Nikolaus Wirth Grundlagen und Techniken des Compilerbaus, spätestens da strecken 99% alle 4 von sich 
normalerweise das Drachenbuch eines oder sogar das Standardwerk.
Taugt die deutsche Übersetzung hier? Bei den meisten Büchern war sie zur Zeit meines Studiums(Mitte/Ende 90er) ja eher grausam, auch bei dem Buch. Da habe ich mir lieber das Original reingezogen.
Daher bin ich den übersetzten Büchern gegenüber immer skeptisch.
Ich war vor paar Jahrzehnten auch mal auf dem Trip, BASIC sei toll, und wenn man es compiled, auch noch schnell. Die ganzen berühmten Beispiele sind eindrucksvoll, will ich gar nicht bestreiten.
Dann fängt man aber früher oder später an, doch ein paar Maschinensprache-Routinen einzubauen, und recht bald fragt man sich, warum man sich eigentlich das BASIC-Geraffel noch antut, es ist nunmal nicht mehr als eine Krücke. Alles, was in BASIC geht, geht auch in ASM direkt, zyklen- und RAM-sparender, sollte man doch irgendwas an BASIC toll finden, kann man ja auch von ASM ins ROM springen oder sich die ROM-Routine einfach ins RAM kopieren (sollte kein BIF Bashing in Sachen ROMRAM trick sein).
Und wenn man gleich in ASM codet, bleibt auch kein Blackbox-Faktor (was genau macht der Compiler aus dem BASIC-Source eigentlich), Vorteil beim Debugging.
Ich will aber auch niemanden demotivieren. Assembler, BASIC, Compiled BASIC, egal... Immerhin MACHT ihr was für den C64 und gafft nicht nur eure Sammlungs-Vitrinen an, spekuliert über Preisentwicklung in der Bucht und spuckt große Töne in der Hardeware-Ecke 
Der Code ist in ASM eben nicht zwingend kleiner, und lesbarer/wartbarer ist ASM auch nicht. Wie gesagt, wenn das alles stimmen würde, wäre Pirates etc. nicht in Basic geschrieben worden (und Hochsprachen wären generell unnötig...).
Debugging braucht man eigentlich mit einem brauchbaren Compiler nicht. Bei z.B. Blitz/Austro-Speed passt das schon.
Der Code ist in ASM eben nicht zwingend kleiner, und lesbarer/wartbarer ist ASM auch nicht. Wie gesagt, wenn das alles stimmen würde, wäre Pirates etc. nicht in Basic geschrieben worden (und Hochsprachen wären generell unnötig...).
Debugging braucht man eigentlich mit einem brauchbaren Compiler nicht. Bei z.B. Blitz/Austro-Speed passt das schon.
Willst du etwa sagen
ist nicht kleiner in ASM? kann ich mir garnicht vorstellen....
gut, für reine PRINT-Orgien, Timing egal, keine nennenswerte Musik: stattgegeben
wenn das alles stimmen würde, wäre Pirates etc. nicht in Basic geschrieben worden (und Hochsprachen wären generell unnötig...).
wenn mehr Leute sich die Mühe machen würden, sich in Assembler reinzufuchsen, dann wäre das in der Tat so
BASIC und andere Hochsprachen sind aus meiner Sicht eben niederschwellige Angebote, z.B. an Otto-Normal-Homecpmputer-Käufer und seine Kinder in den 80ern. 95% dieser User haben niemals etwas anderes als BASIC programmiert, von den verbliebenen 5% entfallen vielleicht 4 auf diejenigen, die noch mit Comal80 Spaß hatten, z.B. in der Schule, und/oder mal stumpf ein Machinensprache-Listing aus einer Zeitung in irgendeinen Checksummer abgetippt haben (zumeist ohne nennenswert zu wissen, was sie da eigentlich tun), das letzte 1% auf Leute, die wirklich mal Assembler ausprobiert haben. Allle Zahlen sind natürlich ausgedacht.
Naja dann wurde Pirates inkl. der VM für eine eigene weitere Hochsprache darin und der Blitz-Compiler inkl. seiner 6kBytes großen in Assembler geschriebenen Runtime wohl von inkompetenten Leuten geschrieben, die schlicht nicht erkannt haben, dass Assembler einfach immer die bessere Wahl ist. Okay.
Und wenn du das alles drauf hast, wirst du feststellen, dass du eigentlich Assembler lernen willst.
das ist vernichtend! 
....die schlicht nicht erkannt haben, dass Assembler einfach immer die bessere Wahl ist.
Das ist richtig! Deswegen schreibe ich selbst Webseiten in Assembler. Das Projekt, dessen einer Teil MOSpeed ist, enthält auch einen einfachen Template-Mechanismus für serverseitige Webseitengenerierung auf Java-fähigen Servern. Man kann die in BASIC oder in Assembler schreiben. Sieht sehr elegant aus: https://github.com/EgonOlsen71…main/webapp/WEB-INF/views
...und läuft mit der von Assembler zu erwartenden Geschwindigkeit: https://jpct.de/mospeed/asm
Leider sind OS, Browser, Server, BASIC-Interpreter, Assembler, 6502-Emulator und alle die sonst so dafür nötigen Komponenten noch in diesen doofen Hochsprachen geschrieben, aber das wird schon noch...
Ich finde das Basic V2 einfach super. Was man da für Konstrukte bauen kann, und die dann auch noch laufen. Zudem der Interpreter, der alles in 8KB inne hat.
Wie gesagt, mein Traum wäre ein Basic-v2-Interpreter und den Austrospeed für die Supercpu, mit 24bit Adressierung.
Ich hatte letztes Jahr damit angefangen, und bin mit dem Compiler auch recht weit gekommen.
Der P-Code kann ab Bank $02 ausgeführt werden, wobei dieser die Bankgrenze nicht überschreiten darf, wegen der 16Bit Adressierung.
PS: Wenn man mit Austro compiliert, und das zu compilierende Programm ändert,
von diesem hier,
10 for i=8192 to 16191:poke i,0:next
nach diesem hier.
10 for i%=8192 to 16191:poke i%,0:next
Dann läuft das Compilat sehr viel schneller ab. Das wusste ich bis heute nicht.
Debugging braucht man eigentlich mit einem brauchbaren Compiler nicht. Bei z.B. Blitz/Austro-Speed passt das schon.
Hahaha... der war gut.
Dann lade ich Dich herzlich ein mit uns an C*BASE zu coden.
von diesem hier,
10 for i=8192 to 16191:poke i,0:next
nach diesem hier.10 for i%=8192 to 16191:poke i%,0:next
Dann läuft das Compilat sehr viel schneller ab. Das wusste ich bis heute nicht.
Steht glaube ich sogar in der Anleitung zu Blitz, das integer Variablen schneller abgearbeitet werden.
