Wie den CC65 Optimizer abschalten?

Es gibt 10 Antworten in diesem Thema, welches 1.697 mal aufgerufen wurde. Der letzte Beitrag (3. Juni 2011 um 23:48) ist von Soulstealer.

  • Hallo,

    laut der Dokumentation zum CC65 soll man den Optimizer abschalten, wenn man den Inline Assembler Code so haben will, wie er eingegeben wurde.
    Bitte melde dich an, um diesen Link zu sehen.
    "If in doubt, check the generated assembler output, or disable optimizations."

    Nur wie :whistling: . Leider kenne ich den Compilerschalter dafür nicht. Wenn ich meine C Inline Assembler Anweisung in ASM Code umwandeln lasse, kommt da immer optimierter Code raus, obwohl z.B. ich -O oder -t c64 nicht eingeschaltet habe.
    Meine C zu Assembler Source Anweisung schaut immer so aus (ohne Parameter):

    Code
    cc65 -o eightychars.s eightychars.c
  • ohne -O ist schon richtig.... was genau ist denn das problem? (zeig mal den/ein asm schnipsel)

  • Hallo,

    ich versuche für den 80 Zeichen Modus von Imran Nazar einen C Wrapper zu schreiben. Das Beispiel habe ich hier gefunden: Bitte melde dich an, um diesen Link zu sehen.
    Also habe ich mir gedacht, was brauche ich von C aus:

    • Initialisierung.
    • den Bildschirm löschen
    • die Zeichen an X,Y setzen


    Also habe ich vor gehabt den Code in diese oben genannten C Funktionen aufzuteilen. Assembler beherrsche ich wie im Vorstellungsthread schon gesagt nur rudimentär ;).
    Wenn versuche den FontBuffer zu erzeugen, indem ich den Inline Assembler benutze, optimiert er mir folgendes statement kaputt.

    Wenn ich den code natürlich im eightychars.s wieder umschreibe, funktioniert es natürlich. Aber da der Quelltext auf C seite für dieses Inlude noch wächst ist es im Moment sehr hinderlich. Herauskommen sollte natürlich sowas ungefähr:

  • die erste massnahme wäre in dem fall alles ein EIN asm statement zu packen, so in der art:

    asm("sei\n" \
    "lda #0\n" \
    "sta bla\n");

    usw

    denn zwischen zwei asm statements darf der compiler machen was er will

  • :platsch: oh man, daran habe ich natürlich garnicht gedacht. Danke, probier es gleich mal aus.

    Edit: Jetzt wird hier nix mehr wegoptimiert. Daran lag es. Danke sauhund.

  • Als ich dann das gesamte Statement fertig hatte, kam wieder das alte Problem.

    aus

    wird leider

  • mmmh, das problem wird der selbstmodifizierende code sein. inline asm läuft grundsätzlich durch diverse compilerstufen, und dabei werden vermutlich alle labels die nicht als sprungziel referenziert sind rausgeworfen.

    was funktionieren sollte, statt bset2i+2 (also einem seperaten label) bset2+8 zu benutzen, dann sollte es gehen :)

    die sauberere methode wäre allerdings die funktion komplett in ein externes asm file auszulagern, dann pfuscht auch der compiler garantiert nicht drin rum :)

  • Unresolved external `weitertun'

    Bei mir fallen viele Befehle einfach weg?

  • Tja, ich habe mir damals damit beholfen, dass ich den Teil in eine reine Assembler Datei geschrieben habe. Dann habe ich im C Teil einfach ein Inline JMP zu dem Assembler Teil gemacht. Der Optimizer hatte das vorher immer wieder wegoptimiert. Das ging Natürlich nur, weil ich eine einzelne Routine anspringen wollte, da musste ich die ASM Datei nur an einen Adresse verschieben, die ich mir merken konnte. Wenn das sehr viele Sprungpunkte werden, kann man den Ansatz vergessen.
    Ich hatte auch in C nur die Funktionsheader generieren (assemblieren) lassen, dann die .s Datei gesichert und in dieser weitergearbeitet und den ASM Teil drangehangen. Danach habe ich die erst in Binärcode kompilieren lassen.
    Allerdings löst das nicht das eigentliche Problem, sondern ist ein einfacher Workaround.

  • Label-Fehler treten scheins nur bei JSR auf. (Gott sei Dank)

    Zitat

    This is a bug. Because the compiler doesn't generate such code, the inline
    assembler doesn't handle soubroutine local label in a "jsr" instruction
    correctly. The label is not marked as referenced (as it should be) and
    therefore deleted later.

    Regards
    Uz

    Ullrich von Bassewitz

    So umgeht man den BUG: