WINAVR mag keinen Vergleich mit 1

[Peter D. (peda)]

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

[Andreas S. (andreas) (Admin)]

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.

[Joerg Wunsch (Gast)]

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.

[Joerg Wunsch (Gast)]

Quatsch natürlich:

if ((i & 6) == 6)

muß das heißen.

[Peter D. (peda)]

@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

[Joerg Wunsch (Gast)]

Durch das Verkürzen kannst Du aber oft genug infolge der Optimierung
den (vermeintlichen) Bug nicht mehr nachweisen.

[Peter D. (peda)]

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

[Andreas S. (andreas) (Admin)]

Das versprochene Listing.

[Matthias (Gast)]

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

[Peter D. (peda)]

@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

[Andreas S. (andreas) (Admin)]

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)

[Andreas S. (andreas) (Admin)]

Geht allerdings nur wenn mit der Option -g kompiliert wurde.

[Peter D. (peda)]

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