Hallo Besucher, der Thread wurde 19k mal aufgerufen und enthält 30 Antworten

letzter Beitrag von ThomBraxton am

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
    http://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ß!

  • 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.

  • @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.

  • Zitat

    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 :)

  • 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.

  • Ä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:



    in einer merkwürdigen Mischschreibweise:



    und in C Schreibweise (mit erfundener Funktion dec_mem):



    Einfacher kann man das wahrscheinlich nicht herleiten. Aber vielleicht sind doch Grafiken Deine größte Stärke :-)

  • ansich ist das schöne bei C (zumindest finde ich das so), daß wenn man die klammern "optisch" gut setzt, kann man C "runterlesen" wie ne zeitung.


    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

  • Zitat

    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

  • ö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

  • Erster Grundsatz sollte sein, dass der Code an sich verständlich bleibt. Auch wenn's bei oftmals Macroverseuchtem C besonders schwer fällt.
    Trotzdem sind Kommentare unerlässlich. Insbesondere was eine Routine macht und welche Ein und Ausgangsbedingungen gelten sollte genau beschrieben sein :prof:

  • 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.

  • Zitat

    ö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.


    Zitat

    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.