Anbei ein Testprogramm, wo eine Routine um 24Bytes größer ist, nur weil ich es gewagt habe auf das Bit 0 zu testen (i & 1). Alle anderen Tests der Bits 1..7 (i & 2) .. (i & 0x80) werden dagegen brav mit SBRS übersetzt. Ist dieser Bug schon bekannt oder behoben ? Ich optimiere -Os Peter
Du scheinst da eine recht gut abgehangene Compilerversion zu verwenden. Ich bekomme beim Kompilieren mit einer aktuellen Version jedenfalls die folgenden Fehler/Warnungen angezeigt: andreas@d700 tmp $ avr-gcc -Os -mmcu=atmega16 -g -o t.elf t.c In file included from t.c:1: /usr/local/avr/avr/include/io.h:3:2: Warnung: #warning "<io.h> is deprecated, use <avr/io.h> instead" In file included from t.c:2: /usr/local/avr/avr/include/interrupt.h:3:2: Warnung: #warning "<interrupt.h> is deprecated, use <avr/interrupt.h> instead" t.c:3:20: signal.h: Datei oder Verzeichnis nicht gefunden t.c:23: error: redefinition of `SIGNAL' t.c:10: error: `SIGNAL' previously defined here Wenn ich die includes anpasse und das Programm kompiliere, dann kann ich das von dir beobachtete Problem nicht nachvollziehen. Listing ist im Anhang.
Gast
#40791
Es gibt noch mehr Enten da drin. "char t;" sollte wohl besser "volatile char t;" sein, ansonsten hat diese Variable ja überhaupt keinen Sinn (und kann gut wegoptimiert werden). Außerdem ist eine Konstruktion wie if (i & 4) if (i & 2) optimierungswürdig: if (i & (4 | 2)) oder gleich if (i & 6) Schade, daß der Compiler das nicht optimiert.
Gast
#40792
Quatsch natürlich: if ((i & 6) == 6) muß das heißen.
@Andreas, in dem Readme steht: WinAVR 20030115 Ich werde mal die neueste saugen müssen und testen. @Joerg, das ist auch kein funktionsfähiger Code, sondern soweit verkürzt, daß der Bug noch klar hervortritt. Z.B. hatte der if(i&2) noch einen else Zweig. Peter
Gast
#40794
Durch das Verkürzen kannst Du aber oft genug infolge der Optimierung den (vermeintlichen) Bug nicht mehr nachweisen.
So die neue Version ist jetzt: WinAVR 20030424 Der 2.Interrupt mit (i&1) ist aber immer noch 68 Byte groß. Dafür ist jetzt auch der 1. Interrupt mit (i&4) von 44 auf 50 Byte angewachsen. Absolut super !!! Wirklich toll !!! Anbei das Listing. Hoffentlich finde ich die alte WINAVR Install noch, damit wenigstens der 1.Interrupt wieder kürzer ist. Peter
Das versprochene Listing.
Gast
#40797
Hi also bei der angehängten Notation erledigt kommt das von dir erwartete Ergebnis raus. Wahrscheinlich hat der AVRGCC ein Problem mit dem verketteten if die ich auch nicht sehr lesbar finde. Matthias
@Andreas, Dein Listing sieht ja o.k. aus. Bloß nützt mir das nichts, da ich nicht weiß, wie ich das reproduzieren kann. Ich habe ja heute die neueste Version auch ohne Erfolg probiert. Und das ich Dir meine Programme zum Compilieren schicke, will ich Dir nicht zumuten. Wie kriegst Du denn die Quellzeilen mit ins Listing ? @Matthias, wie schon gesagt, ich habe da einiges rausgeschnippelt, nicht nur das else beim 2. if. D.h. so kann ich es nicht machen. Peter
Ich verwende nicht die neueste WinAVR-Version, sondern ich habe den Compiler vor ein paar Tagen aus dem aktuellen Quellen selber kompiliert (3.3.1 20030720). Das Listing bekommt man mit avr-objdump -d --source (elf-datei)
Geht allerdings nur wenn mit der Option -g kompiliert wurde.
Danke Andreas,
ich hab jetzt eine Lösung gefunden, kostet nur einen Befehl mehr, also
wesentlich besser als 12 Befehle mehr:
i = PIND<<1; // jetzt kann ich Bit 1 testen (vormals Bit 0)
if( i & 2 )
if( i & 4 )
t++;
else
t--;
Merkwürdig ist die Bit0-Allergie aber doch. Tritt auch nur in
Zusammenhang mit dem 2. if auf.
Peter
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.