www.mikrocontroller.net

Forum: Compiler & IDEs undefined combination of operands


Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich erhalte beim Compilieren eines größeren Programms folgede Warnung:

-------- begin --------
avr-gcc (GCC) 4.1.1 (WinAVR 20070122)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


Compiling: main.c
avr-gcc -c -mmcu=atmega8515 -I. -g -O2 -funsigned-char 
-funsigned-bitfields -fpack-struct -fshort-enums -Wall 
-Wstrict-prototypes -Wa,-adhlns=main.lst  -std=gnu99 main.c -o main.o
C:\DOKUME~1\ich\LOKALE~1\Temp/ccy6aaaa.s: Assembler messages:
C:\DOKUME~1\ich\LOKALE~1\Temp/ccy6aaaa.s:231: Warning: undefined 
combination of operands
C:\DOKUME~1\ich\LOKALE~1\Temp/ccy6aaaa.s:232: Warning: undefined 
combination of operands

Was bedeuted das, und wie bekomme ich das weg ? Die Datei wird 
anscheinend nach dem Compilieren sofort wieder gelöscht, daher kann ich 
nicht nachschauen was an Zeile 231 und 232 steht.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Compiling: main.c
> avr-gcc -c -mmcu=atmega8515 -I. -g -O2 -funsigned-char
> -funsigned-bitfields -fpack-struct -fshort-enums -Wall
> -Wstrict-prototypes -Wa,-adhlns=main.lst  -std=gnu99 main.c -o main.o
> C:\DOKUME~1\ich\LOKALE~1\Temp/ccy6aaaa.s: Assembler messages:
> C:\DOKUME~1\ich\LOKALE~1\Temp/ccy6aaaa.s:231: Warning: undefined
> combination of operands
> C:\DOKUME~1\ich\LOKALE~1\Temp/ccy6aaaa.s:232: Warning: undefined
> combination of operands

> Was bedeuted das,

Dass dem Assembler die Operanden in einem Befehl oder Ausdruck nicht
passen.

Sollte bei Compiler-generiertem Code nicht passieren, kann aber
natürlich gut und gern bei inline asm passieren.

> und wie bekomme ich das weg?

Indem du den Fehler beseitigst. ;-)

> Die Datei wird anscheinend nach dem Compilieren sofort wieder
> gelöscht, daher kann ich nicht nachschauen was an Zeile 231 und 232
> steht.

Ja, das ist eine temporäre Datei.  Du kannst mit
avr-gcc -S -mmcu=atmega8515 -I. -g -O2 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes  -std=gnu99 main.c

den Compiler dazu bringen, den Code lediglich in die Datei main.s zu
compilieren und danach seine Tätigkeit zu beenden.  (Sonst würde er an
dieser Stelle den Assembler rufen.)  Diese Datei sollte bis auf den
Namen äquivalent zu der genannten Datei sein, sodass du darin an Hand
der Zeilennummer den Fehler suchen kannst.

Falls dein Makefile eine Regel dafür hat, genügt auch »make main.s«.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Sollte bei Compiler-generiertem Code nicht passieren, kann aber
> natürlich gut und gern bei inline asm passieren.

Es gibt nur kein inline asm, deshalb ja auch die ganze Frage...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es gibt nur kein inline asm, ...

Muss dir nicht immer gleich bewusst sein.  Die avr-libc erledigt auch
einiges mit inline asm.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von AVR-GCC 3.4.6 zu 4.1.1 wurden sehr viele Änderungen vorgenommen, die 
wohl ne Menge Seiteneffekte haben.
Insbesondere bei der Optimierung gibts einige Überraschungen 
(Reordering, manchmal größerer Code).

In ner Beta des 4.1.1 hatte bei mir sogar ne harmlose switch Anweisung 
Assembler-Warnungen erzeugt.

Der 4.1.1 muß quasi erst noch reifen, während der 3.4.6 bei mir 
keinerlei Probleme machte.


Mit dem Schalter -save-temps kannst Du Dir die temporären Dateien 
ansehen.


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Von AVR-GCC 3.4.6 zu 4.1.1 wurden sehr viele Änderungen vorgenommen,
> die wohl ne Menge Seiteneffekte haben.

Du weißt es ja so genau: welche denn?

> Insbesondere bei der Optimierung gibts einige Überraschungen
> (Reordering, manchmal größerer Code).

Ja, die Optimierung ist komplett neu gefasst worden.  Einige deiner
früheren Lieblingsbeschwerden scheinen sich in Luft aufgelöst zu
haben.  Es wird sehr viel mehr 8-bit-Code erzeugt, wo GCC 3.x noch
16-bit-Code erzeugt hat.  Darüber magst du aber offenbar nicht mehr
sprechen, man kann so wenig jammern drüber.  Sorry, langsam geht mir
deine Polemik aber auf den Senkel.  Die hast du nicht nötig.

> In ner Beta des 4.1.1 hatte bei mir sogar ne harmlose switch
> Anweisung Assembler-Warnungen erzeugt.

Das war ein Problem des (nach wie vor inoffiziellen) ATmega256x-
Patches, bei dem wir uns mit dem Autor des Patches mittlerweile einig
geworden sind, dass die Warnung einerseits sowieso unzureichend war
(da sie nicht alle möglichen Fälle abdecken konnte, in denen sie
gerechtfertigt gewesen wäre) und andererseits zu Verwirrung geführt
hat an Stellen, wo dies nicht notwendig war.

Das heißt nicht, dass Björn sich nicht was dabei gedacht hätte, als er
damals diese Warnung in den Assembler gebaut hat: die Sprungtabellen
zwischen den beiden 128-KiB-Blöcken sind nicht ganz ohne.  Wenn deine
jump table aus dem switch aus Versehen doch eine 128-KiB-Grenze
schneidet, dann kracht's.  Dafür gibt es auch keine Abhilfe, es sei
denn, du würdest den Übergang von 16-bit- auf 32-bit-Zeiger (für
alles, auch RAM-Adressen) für den ATmega256x bevorzugen.

> Der 4.1.1 muß quasi erst noch reifen, während der 3.4.6 bei mir
> keinerlei Probleme machte.

Unfug, der auch von wiederholter Behauptung deinerseits nicht wirklich
richtiger wird.  Das mag für GCC 4.0.x noch halbwegs richtig gewesen
sein, seither sind aber auch schon Jahre ins Land gegangen.
Gegenbehauptung: der GCC 4.1.x optimiert nicht nur deutlich besser,
sondern hat auch einige Bugs gefixt, die der 3.x noch hatte.  Das
Risiko, mit GCC 3.x also Schiffbruch zu erleiden, ist mittlerweile
schon größer, als mit den aktuellen Versionen.

Keine von beiden Aussagen wirst du weder stichhaltig beweisen noch
widerlegen können.  Also hör bitte auf, hier FUD zu verbreiten.

Zum Thema dieses Threads trägt es sowieso Nullkommanichts bei.  Das
dürfte einfach was komplett anderes sein.  Leider mag uns der OP
seinen Quellcode nicht antun, also können wir nur mutmaßen.

> Mit dem Schalter -save-temps kannst Du Dir die temporären Dateien
> ansehen.

Genau wie mit der von mir vorgeschlagenen -S Option.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:

> Du weißt es ja so genau: welche denn?

Sorry, ist natürlich nur mein ganz persönlicher Eindruck.
Es waren halt mehr Anpassungen nötig, wenn ich älteren Code übernommen 
habe, als bei früheren Versionswechseln (Ich weiß natürlich, es liegt 
nur an meinen nicht C-Standard konformen Annahmen).

> Einige deiner
> früheren Lieblingsbeschwerden scheinen sich in Luft aufgelöst zu
> haben.

Nö, das unerwünschte inlining bei -Os macht er immer noch (ja ich weiß, 
man kann inlining global verbieten, aber an anderen Stellen möchte man 
es doch).

>  Es wird sehr viel mehr 8-bit-Code erzeugt, wo GCC 3.x noch
> 16-bit-Code erzeugt hat.  Darüber magst du aber offenbar nicht mehr
> sprechen, man kann so wenig jammern drüber.

Ja, switch geht manchmal sogar 8-bittig. Man darf bloß nicht maskieren, 
z.B. switch(i&0xF0), dann ists wieder 16-bittig.
Ich hatte ja auch einige if-Ausdrücke, die beim 3.4.6 grundlos 16-bittig 
erweitert wurden, muß die mal überprüfen.


Peter

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

>> Du weißt es ja so genau: welche denn?

> Sorry, ist natürlich nur mein ganz persönlicher Eindruck.

Es ist offenbar massiv am Optimierer gearbeitet worden.  Mein erster
persönlicher Eindruck war übrigens völlig gegenteilig zu deinem: knapp
10 % Codeeinsparung.  Allerdings arbeite ich (zumindest im Job) in
einer komplett anderen Kategorie als du, der du mal irgendwo
schriebst, dass du nicht wüsstest, womit du einen ATmega128 auch nur
annähernd füllen könntest.  Wir lasten einen ATmega1281 gut aus,
RAM-mäßig auf jeden Fall, ROM-mäßig so bei 30...50 % zurzeit.

> Nö, das unerwünschte inlining bei -Os macht er immer noch ...

Inlining ist ja nicht generell unerwünscht.  Es kann schließlich zu
kleinerem Code führen und damit der Prämisse von -Os entsprechen.  Ich
habe auch einen Bugreport offen, wo er sich verrechnet hat damit.  Was
mir bei der Diskussion um diesen Report nur wie ein Seifensieder
aufgegangen ist: wenn du Funktionen hast wie diese:
void dosomeasm(uint16_t i)
{
   inline asm("do this" "\n\t"
              "and that" "\n\t"
              "and" "\n\t"
              "way" "\n\t"
              "more"
              :
              : r(i));
}

...dann ist das für GCCs Kostenberechnung erst einmal nur eine einzige
CPU-Anweisung.  Mehr kann er davon nicht sehen.  Entsprechend kann er
davon einige Kopien inline unterbringen, bevor seiner Meinung nach der
Preis für die CALL/RET erreicht ist.  So'ne Funktion muss man daher
also schlicht
static void dosomeasm(uint16_t) __attribute__((noinline));

void dosomeasm(uint16_t i)
{
  ...
}

deklarieren.  Das "static" ist besonders wichtig, wenn die Funktion
ein Kandidat fürs inlining sein sollte (und man es nicht verhindern
möchte/muss), andernfalls wird trotz inlining noch eine separate Kopie
(für die Benutzung als externes Symbol) bereitgestellt.  Aber static
gehört sowieso zum guten Programmierstil.

Der Unterschied zum GCC 3.x hier ist, dass letzterer bei -Os eben nie
versucht hat, Funktionen inline zu erweitern, auch dann nicht, wenn es
wirklich kürzeren Code ergeben hätte.


Aber wie schon gesagt, wir bewegen uns jetzt vom ursprünglichen Punkt
dieses Threads mächtig weit weg.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir bezüglich des neuen Compilers aufgefallen ist:
-o2 erzeugt meist einen schnelleren und kleineren Code als -os.

Ich weiß nicht was ich gemacht habe, auf jedenfall ist diese Warning 
jetzt weg. Aktiv wurde auf jedenfall kein inline asm von mir verwendet. 
Falls doch, dann irgendwo in einem mitgelieferten Makro.
Sobald ich diese wieder hinbekomme (ich hatte sowas schon öfters), dann 
suche ich mal was genau schief läuft.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.