last post from ThomBraxton at the
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.
QuoteOptimierende 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 
Du hast sofort den Grund erkannt, warum ich mich so schwammig ausgedrückt hab
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! 
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.
Keiner da heute, na dann kann mir ja vielleicht Morgen wer etwas weiterhelfen!
Ä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
Hallo Skoe mein Freund,
ja jetzt wird mir so manches klarer! Danke, ich war auf dem sogenannten Holzweg
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
Quotezudem: 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
joar is was dran.... wollte das halt nur erwähnen weil doku ist des programierers stiefkind 
außerdem ists grade am anfang sehr hilfreich wenn man sich direkt daneben schreibt was da grade gemacht wird....
Quotewenn 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
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 
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.
Quoteö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.
QuoteVor 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.
