Moin Leute, ich habe mal wieder ein Problem: Bei meinen gelegentlichen Kontrollen der LST-Files habe ich festgestellt, daß der Compiler grundsätzlich alle Variablen auf 16-Bit-Breite erweitert. Ich schreibe z.B. eine Funktion, in die ein unsigned char übergeben wird und vergleiche dann in der Funktion den Parameter mit einer Konstanten (die auch <=255 ist). Dann erzeugt der Compiler schon vor dem Aufruf der Sub-Funktion einen 16-Bit-Wert für den Parameter. Mit diesem führt er dann den Call aus und vergleicht dann mit der Konstanten, die er wieder auf 16Bit erweitert. Das kostet doch unendlich Speicher und Rechenzeit. Kann man das abschalten? Besonders kompliziert wird das beim Indizieren eines Arrays. Der erweitert den Index auf 16Bit und muß dann die anschließende Multiplikation (mit der Variablenbreite) und die Addition des Offsets mit einem riesen Aufwand durchführen. Help, Markus
Es kostet nicht ,,unendlich'', aber ja, es kostet. Die Benutzung von int ist aber für sowas per C-Standard vorgeschrieben. Es gibt eine Kommandozeilenoption -mint8, damit kannst Du das abschalten, allerdings ist der Compiler dann nicht mehr nur nicht standardkonform, sondern es erlischen auch alle Deine Garantieansprüche für die avr-libc. :-) Sprich, avr-libc ist nicht hinsichtlich Kompatibilität zu -mint8 getestet oder auch nur begutachtet worden. Einfache Dinge können noch funktionieren, aber wir garantieren gar nichts. <inttypes.h> haben wir kürzlich zumindest mal so geändert, daß auch bei -mint8 wenigstens die explizit benannten Typen (int8_t, int16_t usw.) noch korrekt sind. Kurioserweise gibt es bei -mint8 keinen 32-Bit Integer Typ, wohl aber noch einen 64-bit Integer (long long int).
Hallo Jörg, das mag ja alles für integers stimmen, aber ich übergebe doch in die Funktion einen unsigned char. Und char sowie unsigned char sind doch nur 8 Bit breit?! Ich habe jetzt auch noch mal etwas rumexperimentiert. Wenn ich eine lokale Variable (char oder unsigned char) definiere, dann arbeitet er auch nur mit einem Register. Das sieht so aus, als ob er das nur bei Funktionsaufrufen erweitert. M
Ein char ist in der C-Sprache auch ein Integer Datentyp. Ja, Funktionsaufrufe werden in der Tat erweitert. Siehe auch http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/FAQ.html#faq_reg_usage Außerdem kann man zuweilen mit geschickten Casts verhindern, daß der Compiler einen Ausdruck erst komplett in einen int wandelt: http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/FAQ.html#faq_intpromote Liest eigentlich auch hin und wieder jemand die FAQ? :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.