C-Kurs, Abend 6 - Lösungen und Fragen


    • skoe
    • 10864 Aufrufe 30 Antworten

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • C-Kurs, Abend 6 - Lösungen und Fragen

      So, lange hat's gedauert. War inzwischen mit dem Malprogramm beschäftigt. Aber hier ist die nächste Folge des C-Kurses.

      Auch heute wieder ein Dankeschön an ogd für's Probelesen und Verbessern!

      Abend 6: Der springende Punkt
      skoe.de/wiki/doku.php?id=ckurs:06-abend6

      Fragen und die Lösungen zu den Aufgaben könnt ihr hier posten und diskutieren.

      Für Verbesserungsvorschläge mach ich wieder einen extra Thread auf.

      Viel Spaß!
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Bau Dir ein eigenes Modul! EasyFlash

    • Hallo,

      ich versuche mich mal an den Fragen:

      1) Die C-Statements werden im Assembler-Quelltext als Kommentare über den generierten Code geschrieben.

      2) Ist der Divisor als 2^n darstellbar, wird die Routine tosasrax mit dem Wert n im Akku aufgerufen.
      Ist der Divisor ein anderer, wird die Routine tosdiva0 mit dem Divident im Akku aufgerufen.

      Grund: Bitshifting als Multiplikation bzw. Division ist schneller in der Abarbeitung, als eine entsprechende Assembler-Routine.
      ?STRING TOO LONG ERROR IN 10
      READY.
      █

    • @Ehrlicher: Klingt richtig. Ich kann mich erinnern, außerdem noch etwas anderes gesehen zu haben. Ich schau heute abend nochmal.

      Im Wiki habe ich übrigens die fehlenden Grafiken zu den Festkommazahlen wiederhergestellt. Vielleicht lohnt es sich, da nochmal raufzuschauen.

      Außerdem gibt es dort einen neuen Hinweis zu den neuen Operatoren:

      Beim Postfix-Operator muss sich der Code erst den alten Wert von i aus dem Speicher holen, diesen dann inkrementieren/dekrementieren und in den Speicher zurückschreiben. Dann kann/muss der Code den alten Wert von i weiterverwenden. Das führt aber dazu, dass der alte Wert von i zwischengespeichert werden muss, was zu längerem Code führt. Wenn der Wert nicht direkt verwendet wird, z.B. in for (i = 0; i < 5; ++i), sollte man sich deshalb immer für ++i statt für i++ entscheiden. Optimierende Compiler erzeugen übrigens in beiden Fällen den gleichen Code. Mit dem cc65 ohne Optimierung (also ohne -O) kann man den Unterschied sehr gut beobachten.
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Bau Dir ein eigenes Modul! EasyFlash

    • Optimierende Compiler erzeugen übrigens in beiden Fällen den gleichen Code. Mit dem cc65 ohne Optimierung (also ohne -O) kann man den Unterschied sehr gut beobachten.


      wobei da cc65 nicht alles "schluckt", also sollte man auch wirklich nur dann x++ schreiben wenn man auch x++ meint :)

    • :) wobei es halt auch nicht schadet es "richtig" hinzuschreiben wenn man mit "grossen" compilern arbeitet. grade bei so simplem zeug am anfang braucht man eigentlich fast nie "x++" und "++x" tuts genauso (und ist sogar richtiger).

    • Hallo Boy's & Girl's! :winke:
      Ich habe den C - Kurs bisher verfolgt, aber ich muß sagen wir zwei beide also C und ich werden sicher keine Freunde!
      Es ist mir einfach zu kompliziert gegenüber ASM, sorry aber ich weiß jetzt warum ich C immer gemieden habe. Diese Verschachtelung von den verschieden Klammern da steigen einem ja die Haare zu Berge. Vielleicht kann mir einer einen Tipp geben und ich sehe das ganze zu kompliziert.

      Würde mich darüber freuen! Danke an die C Supercoder und an alle anderen.
      Gerald ( gh23 )

      ________________________________________
      Stur lächeln und winken Männer

    • Ähm, was willst Du denn hören? Wenn Du die schließenden und öffnenden Klammern richtig einrückst, z.B. wie im Kurs, sind sie leicht wiederzufinden.

      Oder anders gesagt:

      Quellcode

      1. bla:
      2. ldy #0
      3. l1:
      4. ldx #0
      5. l2:
      6. dec $d020
      7. dex
      8. bne l2
      9. dey
      10. bne l1
      11. rts
      Alles anzeigen


      in einer merkwürdigen Mischschreibweise:

      Quellcode

      1. bla:
      2. {
      3. ldy #0
      4. {
      5. l1:
      6. ldx #0
      7. {
      8. l2:
      9. dec $d020
      10. dex
      11. bne l2
      12. }
      13. dey
      14. bne l1
      15. }
      16. rts
      17. }
      Alles anzeigen


      und in C Schreibweise (mit erfundener Funktion dec_mem):

      Quellcode

      1. void bla(void)
      2. {
      3. unsigned char x, y;
      5. y = 0;
      6. do
      7. {
      8. x = 0;
      9. do
      10. {
      11. dec_mem(0xd020);
      12. --x;
      13. } while (x);
      14. --y;
      15. } while (y);
      16. }
      Alles anzeigen


      Einfacher kann man das wahrscheinlich nicht herleiten. Aber vielleicht sind doch Grafiken Deine größte Stärke :)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Bau Dir ein eigenes Modul! EasyFlash

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von skoe ()

    • zudem: kommentieren ist ein MUSS bei C wie ich finde. keine aufsätze aber zb ne variablenerklärung im kopf hilft nachher wunder wenn man nach tagen/wochen/monaten etc das teil wieder aufmacht


      kommentare sind in jeder programmiersprache ein muss. im durchschnitt sollte der code mehr kommentarzeilen als codezeilen haben

    • wenn man sich direkt daneben schreibt was da grade gemacht wird....


      wobei man da vorsichtig sein muss. ein beliebter fehler ist als kommentar hinzuschreiben was eh im code steht, und nicht *warum* das was da steht gemacht wird.

    • öhmmm...., nicht soviel mit dem Text rumsabbern.

      Eigentlich sprechen die C-Befehle für sich.

      Vor einer Funktion eine kurze Erklärung und fertig und nicht immer schreiben : " 3 Bit nach rechts schieben", "3.Bit invertieren", so ein scheiss findet man hier oft in "C".

      mfg

    • Vor allem bei Zugriff auf Hardwareregister kann es nicht schaden, Sinn und Zweck zu kommentieren. Ok, d020 kann ich mir noch merken, aber bei diversen anderen Registern, die man eher selten braucht, müsste ich ansonsten öfters mal in der Memory Map nachgucken - das kann dann schon etwas lästig werden.

    • öhmmm...., nicht soviel mit dem Text rumsabbern.
      Eigentlich sprechen die C-Befehle für sich.


      genau. darum schreibt man in kommentare sinnvollerweise auch nicht WAS passiert sondern WARUM etwas passiert. was passiert steht ja schon im code.

      Vor einer Funktion eine kurze Erklärung und fertig und nicht immer schreiben : " 3 Bit nach rechts schieben", "3.Bit invertieren", so ein scheiss findet man hier oft in "C".


      das ist genau die art kommentare die in der tat sinnfrei sind - ausser natürlich wir reden von beispielcode für anfänger.