> Der AVR-GCC ist da
> leider etwas optimierungsfaul.
Es hat ihm einfach nur niemand beigebracht. Für die meisten
GCC-Architekturen ist das kein Thema, weil deren natürliche
Verarbeitungsbreite größer ist (32 bits) als die vom Standard
geforderten 16 bits. Dadurch ist bei ihnen die Verarbeitung
von 8-Bit-Werten nicht schneller als die von 16- oder 32-bit-
Werten (oft eher noch langsamer).
Kommt hinzu, dass wohl die AVR-GCC-Implementierung insgesamt
eher vorgaukelt, eine 16-bit-Implementierung zu sein, d. h. die
internen Befehle (insns) sind in der Zwischensprache als
16-bit-Befehle organisiert, die dann jeweils in den Assemblercode
für eine 16-bit-Operation direkt auflösen. Hier liegt sicher
Optimierungspotenzial, leider jedoch in einer Form, dass man
praktisch einen Großteil der existierenden Implementierung
neu anfangen müsste, wollte man das ändern.
Übrigens schreibt der Standard nicht "Promotion auf mindestens
16 bits" vor, sondern "Promotion auf int". D. h. obige Rechnung
bewirkt zwischenzeitlich ein Ergebnis, das mit einem u. U.
fehlerhaften Vorzeichen behaftet sein könnte, welches anschließend
bei der Zuweisung auf uint16_t wieder vernichtet wird. In
diesem speziellen Fall nur ,,könnte'', da ADCH nur einen
Wertebereich von 0 bis 3 hat, mithin immer positiv ist. Aber
solche impliziten Vorzeichenmutation bergen eine Gefahr in
sich, siehe
http://www.mikrocontroller.net/forum/read-2-368138.html
An den OP:
hätte es übrigens auch getan. ;-)
