Kann man eigentlich mit (ggf. welchen) Compilern festlegen, wo im Speicher das Kompilat landet?
Fragen zu Compilern
-
TheRyk -
18. Mai 2010 um 20:13 -
Erledigt
Es gibt 14 Antworten in diesem Thema, welches 2.984 mal aufgerufen wurde. Der letzte Beitrag (
-
-
ich glaube basicboss konnte das.... eventuell auch blitz!
-
Konnte BasicBoss das? Eventuell mal den BasicBossCrosscompiler hier aus dem Forum abchecken - wenn das nicht geht, kann der Autor vielleicht dran drehen.
Wo das eigentliche Kompilat (ausgehend von so Dingern wie Basic64, Blitz/Austro, Petspeed, Laser oder wie der hiess) liegt ist im Prinzip auch völlig egal. Wichtig ist wohl eher wo der Interpretercode läuft. Bei den vorgenannten gibt es da wohl keine Möglichkeit (ausser resourcen) von $0801 wegzukommen. RTL-64 legt den Interpreter wohl unter das Basic ROM, könnte auch eine Kernalversion geben, bin ich mir nicht sicher. Dass ist der Compiler mit dem z.B. Silent Service compiliert wurde.
-
Irgendwie natĂĽrlich logisch, dass wenigstens die Startzeile irgendwo bei $0800 liegen wird.
Dachte mir aber, dass man alles andere evtl. bestimmen kann. Will das hauptsächlich wissen für Verbindung von Kompilat mit Assembler.Danke für die Info jedenfalls! Jetzt habe ich ein bisschen was zum Rumprobieren.
-
Dann verbinde doch wie du lustig bist und behandle das Kompilat wie ein normales Basic-Programm - das ists ja eigentlich auch - mit wachsendem Variablenspeicherverbrauch und allem. Das Ende des Basicspeichers zu beschränken machen eigtl. auch alle Compiler problemlos mit.
Edit:
Zitat
Jetzt habe ich ein bisschen was zum Rumprobieren.
Hattest du vorher mit Sicherheit auch - warst nur zu faul.
-
Ja, stattgegeben in punkto Faulheit

Werde den Rat beherzigen. Grundsätzlich kann ich für Verbindung eines Basic-Programms/Kompilats mit Assembler doch vor allem ab $C000 machen, was ich will in Assembler oder? IIRC kann BASIC doch mit den oberen Speicherbereichen so direkt eh nix anfangen (abgesehen von Bankswitch).
Und gibt es noch Tipps, wie ich aus einem Basic-Programm/Kompilat und einem Assembler-Code am einfachsten einen One-Filer schmiede?
-
Man kann mit den Pokes poke43, lo(adr):poke 44, hi(adr) den Basic Start verlegen und dann das Assembler Programm zwischen sagen wir mal $0900 und den neuen Basic Start quetschen. Wenn das Basic Programm fertig ist, schreibst du am alten Basic Start, also bei $0801 eine Zeile Code mit den entsprechenden Pokes zum verlegen des Basic Starts und einem run. Habs zwar jetzt nicht nochmal ausprobiert, aber irgendwann vor Jahren hab ich das mal gemacht.
Meiner Meinung nach wäre auch der CC65 was für dich. In C kann man sich einigermassen schnell einfummeln.Grüße
Monte
-
Danke, Monte.

Ich probiere den Tipp mit dem BASIC-Startverlegen auf jeden Fall auf.
Ob und wann ich mich wirklich in C einfuchse, naja. Mal sehen.

PS: Meine Frage war aber noch niveauloser gestellt, wie kriege ich beides in 1 File. Z.B. in VICE ĂĽber Monitor die Teile in den Speicher laden und speichern? Oder im ASM-Code das Kompilat als !bin reinziehen?
-
Kann man eigentlich mit (ggf. welchen) Compilern festlegen, wo im Speicher das Kompilat landet?
BasicBoss kann das. Man kann sogar festlegen wo das Programm, die Daten(z.b. Data Zeilen) und die Variablen starten sollen. Gab dazu entsprechende Compileranweisungen. Steht alles in der Anleitung: (Bitte melde dich an, um diesen Link zu sehen.)
-
Meine Frage war aber noch niveauloser gestellt, wie kriege ich beides in 1 File. Z.B. in VICE ĂĽber Monitor die Teile in den Speicher laden und speichern? Oder im ASM-Code das Kompilat als !bin reinziehen?
Beides geht natürlich und während man rumentwickelt ist ein !bin vmtl. sogar am sinnvollsten - wenn man das aber mastern tut nimmt man sich einen Packer/Linker (z.B. Crosslinker, MDG Packer am c64 oder exomizer am pc), müllt den kram zusammen und fertig.
-
Noch ist der BASIC Code eigentlich so banal, dass sich das Kompilieren kaum lohnt und es wahrscheinlich einfacher wäre, das direkt in ASM zu coden

Aber in der Tag werde ich wohl mal versuchen, Kompilat als !bin einzubinden, das klingt gut. Mit Exomizer arbeite ich schon, läuft auch gut für einfaches Packen von 1-filern, mit dem Linken habe ich da leider noch keine Erfahrung bzw. das Manual noch nicht gescheckt.
-
Grundsätzlich kann ich für Verbindung eines Basic-Programms/Kompilats mit Assembler doch vor allem ab $C000 machen, was ich will in Assembler oder?
ja, das ist der klassische weg.IIRC kann BASIC doch mit den oberen Speicherbereichen so direkt eh nix anfangen (abgesehen von Bankswitch).
auch für alles grafische wie bildschirme, zeichensätze oder sprites ist dieser bereich gut zu gebrachen, weil der vic-ii-chip auf das brachliegende ram unter den roms zugreifen kann. -
Mal wieder 'ne vielleicht blöde Frage.
Ein sinnvoller Grund, BASIC statt Assembler zu benutzen, sind ja die etwas einfacheren Operationen mit Strings. Nach dem Kompilieren kann doch die in BASIC nervige Bitte melde dich an, um diesen Link zu sehen. eigentlich nicht mehr vorbei kommen, weil sie ein reines Problem des BASIC-Interpreters ist, oder sehe ich das falsch? Entsteht in ASM ĂĽberhaupt String-MĂĽll?
-
Naja, ich befürchte mal, da wird Dir ein Basic-Compiler nicht helfen, die Strings müssen ja trotzdem angelegt, verwaltet und gelöscht werden und irgendwann geht der freie Platz aus. Auch in einem Kompilat wird A$=A$+"*" dazu führen, dass der alte A$ entsorgt wird und ein neuer A$ angelegt wird. Und das in einer Schleife, dann hast Du den Salat - äh - die Garbage Collection wieder.Ob das die gleiche wie beim Interpreter oder eine eigene ist, hängt dann wohl vom Compiler ab, wobei ich mal davon ausgehen würde, dass die meisten Compiler die Kernal-Routinen benutzen - wozu alles nochmal erfinden?
Das würde nur dann nicht passieren, wenn tatsächlich bei einer Zuweisung notfalls benötigter Platz hinter der Stelle des aktuellen Strings durch Verschieben aller Strings dahinter geschaffen wird, um dann die neuen Zeichen an den bestehenden String anzufügen. Aber das würde dem Sinn und Zweck eines Compilers - schnelle Basic Programm zu erzeugen - irgendwie widersprechen, wenn jede popelige Stringzuweisung zu einem kilobyteweisen Verschieben von Daten führen würde.Aber wissen tu ich das nicht, das ist mehr ein "educated guess", wie es so schön heißt...
-
Okay, wenn Du Recht hast, ist das auch kein Problem. Man muss es nur wissen, damit man dann trotz Kompilieren die GC hin und wieder mal gezielt an unkritischen Punkten ausführt, damit das Programm nicht an Stellen hängt/auf die Müllabfuhr wartet, an denen es stört.