Dieses Makros kann der Compiler wunderbar optimieren, wenn bit und value
Konstanten sind. Aus "writeBit(PortA,3,1)" wird zum Beispiel "PortA|=1".
Aber Makros finde ich häßlich, vor allem wirken sie sich auf
Fehlermeldungen störend aus. Wenn ich sie intensiv nutze, meldet mir der
Compiler in Fehlermeldungen oft (aber komischerweise nicht immer)
falsche Zeilen Nummern.
Deswegen erwäge ich, lieber Funktionen/Prozeduren zu verwenden. Aber
dann klappt die Optimierung nicht mehr so gut, oder doch?
Wie kann ich das so verbessern, dass sowohl der Funktionsaufruf als auch
der if-Ausdruck weg optimiert werden, sofern bit und value Konstanten
sind?
Und was gehört an der Stelle ??? hin?
Ich finde extra Funktionen für Zuweisungen zu umständlich.
Ich belasse es daher bei Zuweisungen.
Eine Zuweisung an eine Bitvariable geht einfach über ein Macro:
Stefan schrieb:> Wie kann ich das so verbessern, dass sowohl der Funktionsaufruf als auch> der if-Ausdruck weg optimiert werden, sofern bit und value Konstanten> sind?
Sollte circa so gehen:
Yalu X. schrieb:> Dann erzeugt der Compiler (ab Version 4.3) wie erwartet SBI- bzw.> CBI-Instruktionen, wenn die Argumente bit und value konstant sind.
Allerdings ohne Garantie :-P
>> Dann erzeugt der Compiler (ab Version 4.3) wie erwartet SBI- bzw.>> CBI-Instruktionen, wenn die Argumente bit und value konstant sind.>>Allerdings ohne Garantie :-P
Und für PORTF hoffentlich nicht;)
holger schrieb:> Und für PORTF hoffentlich nicht;)
Der Compiler hat keine Vorstellung von PORTF — braucht er auch nicht.
Alles was er wissen muß ist die Adresse, denn die legt fest, ob die
Instruktionen SBI, CBI, IN, OUT, SBIS, SBIC verwendet werden dürfen oder
nicht.
Stefan schrieb:> Aber> dann klappt die Optimierung nicht mehr so gut, oder doch?
Funktionen sind Makros grundsätzlich und immer vorzuziehen, falls
irgendwie möglich. Makros haben keinen Typ, keinen Scope, bringen die
Syntax durcheinander etc. Wenn man inline-Funktionen verwendet klappt
die Optimierung genau so gut (wenn der GCC sich trotzdem weigert die
Funktion zu inlinen, __attribute__((always_inline)) dranschreiben).
Headerfiles mit Tausenden #defines (siehe CMSIS...) sind wie ein Feld
voller Tretminen, verwendet man einen "falschen" (per #define
vorbelegten) Bezeichner gibt es obskure Fehlermeldungen. Versehentliche
Doppel-Verwendung von Funktionsnamen funktioniert entweder (je nach Art
der Verwendung & Scope) oder führen zu sinnvollen Fehlermeldungen.
doublefoo1;// funktioniert nicht, gibt lustige Compilerfehler
6
doublefoo2;// funktioniert; die globale foo2-Variable wird "unsichtbar"
7
}
Deklarationen in einem inneren Scope (hier der Funktionskörper von main)
können Deklarationen im äußeren Scope (hier der globale Scope)
überdecken; bei Macros geht das nicht.
Dr. Sommer schrieb:> Deklarationen in einem inneren Scope (hier der Funktionskörper von main)> können Deklarationen im äußeren Scope (hier der globale Scope)> überdecken; bei Macros geht das nicht.
OK, überredet. ;-)
