Forum64

Quoted from "7Saturn"

der noch was nützliches beiträgt.

Ich denke die Lösung deines Problems ist ein EasyFlash Modul. Platz für maximal 1MB, so groß wird kein Programm ... ;)

Quoted from "TheRyk"

Die Ladegeschwindigkeit ist noch nichtmal so entscheidend, man könnte ja vorher einen Loader mit Software-Speeder schalten. Dass sehr viel RAM beim Kompilieren draufgeht und irgendwo ab 202 + X Blocks pro File normalerweise Ende der Fahnenstange ist, macht schon eher Probleme. Wenn man also (nicht ganz sauber, wie oben ausgeführt) mal einen pauschalen Faktor wie 2,5 annimmt, dürfte also der Basic-Code nur etwa 80 Blocks haben, das ist bei umfangreicherer Software schneller erreicht, als mancher vielleicht denkt.

Man muss sich eben wirklich fragen bzw. testen, ob ein Compiling nennenswert Performanche/Speed bringt <-- für mich der einzige plausible Grund Compiler zu nutzen. Ein Programm, das in Basic eh schon flott läuft, wird durch Compiling nicht besser. Ein Actionspiel oder auch eine - unkompiliert - sehr lahm arbeitende Anwendung ist dagegen schon eher lohnenswert.

Weiß nicht genau ob ich das hier von dir richtig verstanden habe -Faktor wie 2,5 annimmt, dürfte also der Basic-Code nur etwa 80 Blocks haben- aber ich habe zb. heute erst ein 136 Blocks großes Programm auf 123 Blocks compiliert. (Austro Comp)

Quoted from "e.b"

Austro Comp

Ich habe den Austro Comp als P-Code (kein Assembler, sondern vorgeparstes Basic) Compiler in Erinnerung. Bis zu einer bestimmten Originalgröße wird das Komplilat größer. Das liegt an dem Runtime-Modul, das vor das Kompilat gelinkt wird und einn festen Umfang hat. Ab einer bestimmten Originalgröße, wird das Kompilat wegen des kompakten P-Codes wieder tendenziell kleiner. Eine Faustformel habe ich nicht mehr im Kopf. Ist 25 Jahre her.

Quoted from "e.b"

Weiß nicht genau ob ich das hier von dir richtig verstanden habe -Faktor wie 2,5 annimmt, dürfte also der Basic-Code nur etwa 80 Blocks haben- aber ich habe zb. heute erst ein 136 Blocks großes Programm auf 123 Blocks compiliert. (Austro Comp)

Wie gesagt, sicherlich kommt es wirklich darauf an, WELCHE Basic-Befehle vornehmlich kompiliert werden. Kann auch sein, dass der Faktor bei kleineren Progs so ungünstig ist und dann bei größeren günstiger wird.

Reden hier alle von Grösse ohne Sinn und Verstand...

Speicherverbrauch ist auch ein ganz anderes Thema als Speicherplatz auf Disk nebenbei. Und wenn schon alle Compiler zusammengeschmissen werden, dann bitte dazu erwähnen, dass so einige z.B. auch nicht so einfach ihren P-Code unter das Basic ROM legen können.

Die meisten, wenn nicht alle Compiler, gucken sich an was die vorfertigen müssen um dem Programm gerecht zu werden, verschätzen sich auch gerne mal bei "exotischen" Dingen wie Arrays und generieren dann Runtime + P-Code + vorgefertigter Bereich für Variablen. Wie man sich das nun überschlagsweise schönrechnen will mit x,y Faktoren wäre mal interessant, denn der P-Code alleine ist kürzer als der Basic Code. Es gibt also eine Peak"grösse" ab der das Compilat eigentlich zunehmend kleiner wird im Verhältnis zum Original. ROM interpretierter Basic Code beginnt auch erst nach dem RUN zusätzlich RAM zu fressen und dann irgendwann stehen zu bleiben. Compiler meckern eigentlich wenns insgesamt nicht passt.
Bei Austro und Blitz ist der Peak so ab 90-100 Blocks meist.

Quoted from "Balacuda"

... Reden hier alle von Grösse ohne Sinn und Verstand...

Speicherverbrauch ist auch ein ganz anderes Thema als Speicherplatz auf Disk nebenbei.

Ist schon klar, wurde auch schon angesprochen. (EDIT: oder doch nicht? Naja, sollte eigentlich klar sein.)

Je mehr man über den Compiler weiß, desto besser kann man RAM-Vergabe im Kompilat selbst beeinflussen, um "Verschwendung" zu vermeiden. Boss erlaubt z.B., Variabeln-Speicher, Heapend und Co. auch hardcoded selbst festzulegen.

Quoted from "Balacuda"

Bei Austro und Blitz ist der Peak so ab 90-100 Blocks meist.

Bei Boss angeblich wesentlich höher, bin aber niemals in diesem Dimensionen gelandet.

Gerade mal wieder etwas mit Code >100 Blocks rumgepfuscht, mit Austro wurde es am kleinsten, aber irgendwie blicke ich da ohne tut auch zu wenig durch, um mit dem Kompilat was anzufangen. Boss ergab mal wieder riesigen, ohne weiteres kaum händelbaren Kram (250 Blocks oder so, lol). Mit dem Ergebnis von Blitz bin ich am zufriedensten, Kompilat wurde immerhin kleiner und nicht größer und lässt sich später ganz gut mit assembler verarbeiten.

Beim Boss sind ein paar nette Gimmicks wie FASTIF, FASTFOR usw., die man nutzen kann. Der Gewinn an Performance-Speed hängt natürlich an verschiedenen Faktoren. Wenn man in BASIC schon sehr sauber programmiert (RAM-ökonomisch und schnell, evtl. sogar Interrupts OFF), ist der Gewinn kleiner, als wenn man es einfach hinrotzt und kompiliert. Es gibt Basic-Programme, die bereits so schnell laufen, dass sich Kompilieren allein wegen der Performance-Geschwindigkeit kaum lohnt, sondern höchstens, um etwas besser mit Assembler zu harmonieren (und DANN kann man es ja auch wieder sehr schön crunchen, so dass am Ende doch was kleineres rauskommt).

Quoted from "TheRyk"

evtl. sogar Interrupts OFF

Wie meinst du das genau?

Quoted from "TheRyk"

um etwas besser mit Assembler zu harmonieren

Das "harmonisieren" verstehe ich jetzt genausowenig wie das oben stehende "lässt sich später ganz gut mit assembler verarbeiten".

Du kannst auch mit BASIC die Interrupts ausknipsen, wenn Du sie nicht brauchst, wird hier erklärt: http://www.c64-wiki.de/index.php/Interrupt. Beschleunigt natives Basic schon in manchen Fällen recht gut. Ich selbst habe am Ende doch wieder drauf verzichtet (wozu greift man denn auf Basic zurück, wenn man sich der wirklich bequemen sachen beraubt...) oder halt OFF vor längeren Prozessen und wieder ON, wenn ich Interrupts brauchte. Paradebeispiel ist womöglich Colt Seavers' Bertram der Bandwurm, mal in den Code schauen: http://csdb.dk/release/?id=77493. Läuft unkompiliert wahnsinnig schnell. Das würde aus Speed-Gründen niemand kompilieren, im Gegenteil: dann müsste man wieder Verzögerungen einbauen.

Harmonie: Nunja, damit meinte ich lediglich, dass man (offenbar im Gegensatz zu Austro und Blitz) beim Boss (auch dank guter Doku) recht komfortabel festlegen kann, wo das Kompilat im Speicher landet, von wo bis wo Variablenspeicher, String-Heap und Co gehen sollen (z.B. HEAPSTART/-END $XYZ). Natürlich kann man den Basic-Start auch anders verbiegen, keine Frage. Und angeblich soll man ja auch unkompiliertes Basic crunchen können mit Exomizer (aber das habe ich noch nie versucht, beschränke mich da mangels doku auf 08/15-crunchen, weil ich einfach nicht durchblicke bei dem Teil, möglich, dass ich zum Crunchen bald auf irgendein Old-Skewl-Tool zurück greife).

Quoted from "Balacuda"

Reden hier alle von Grösse ohne Sinn und Verstand...

Alle, das bist auch Du...

Quoted from "Balacuda"

denn der P-Code alleine ist kürzer als der Basic Code.

Das kan sein, muß es aber nicht. BASIC braucht fünf Byte pro Zeile (inclusive Zeilennummer), plus eins für jedes Schlüsselwort, plus eins für jedes Zeichen. Kurze Befehle wie STOP oder NEXT F brauchen cimpiliert weniger; sobald Du Formeln mit Fließkomma-Berechnungen hast, oder Befehle die sich nicht mit einem P-Code-Token abbilden lassen, gerät der Compiler sehr schnell ins Hintertreffen. Bei Formeln mit Integer-Variablen oder ausführlich kommentiertem Quelltext ist dagegen der Interpreter im Nachteil. Etc. pp.

Quoted

Befehle die sich nicht mit einem P-Code-Token abbilden lassen, gerät der Compiler sehr schnell ins Hintertreffen.

Schöner wäre hier sicherlich das Beispiel DATA oder PRINT Wüsten (insb. mit viel Integer Abfall) gewesen, denn die nehmen und geben einem Compilat idR nichts. Das mag bei Basic Boss anders als bei Austro/Blitz/Basic64/RTL sein. Dinge die sich nicht abbilden lassen werden z.B. von Blitz zügig an den Basic Interpreter durchgereicht - insb. auch Befehle von manchen Basic Erweiterungen etc. werden im Compilat ebenso wie in (nicht-)"Basic-Tokens" im Speicher abgelegt.
Natürlich findet sich in diversen Zeilen immer wieder was wo der Compiler schlechter abschneidet, aber ab einer gewissen Länge (und davon war bereits vorher die Rede, da noch auf die Zeilenlängen einzugehen ist ja mehr kleinkarieren als ich sonst tue) muss IMHO der Compiler gewinnen - mindestens was P-Code (minus Runtime minus Variablendefinitionshaufen) vs Basic angeht. Man bedenke nur all die eingesparten Doppelpunkte!!11!