2er Komplement mit AVR GCC

Hi Leute, unter Assembler gibts beim AVR ja den Befehl NEG für das 2er Komplement. Ich möchte jetzt unter C eine Variable mit dem 2er-Komplement negieren. Wie mache ich das, damit der Compiler auch wirklich den NEG-Befehl verwendet?

Wenn ich das mit dem Inline-Assembler machen will, weiß ich nicht, wie ich die jeweilige Variable im Assembler nutzen kann.

Gruß Michael

Reply to
Michael Rübig
Loading thread data ...

Einfach "-" davorschreiben?

Vinzent.

Reply to
Vinzent 'Gadget' Hoefler

Michael Rübig schrieb:

Einfach negieren, was sonst?

unsigned char foo; extern void dummy(void);

int main(void) {

for (;;) { foo = -foo; dummy(); } return 0; }

generiert:

.L2: lds r24,foo neg r24 sts foo,r24 rcall dummy rjmp .L2

(Der dummy() wird nur für den einfachen Testfall benötigt, um den Compiler zu überreden, das nicht alles gleich wegzuoptimieren.)

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc
Reply to
Joerg Wunsch

Hi,

Oh Mann, das war schwach von mir.

Danke Michael

Reply to
Michael Rübig

Beim AVR kenn ich mich nicht aus - aber ein bischen mit dem GCC für den SH2 von Renessas.

Beispiel für nen SH2 von Renessas einer inline Assembler Anweisung:

volatile int var1 = 10; volatile int var2 = 20; asm( "mov %0, r2" : : "g"(var1) ); asm( "mov %0, r3" : : "g"(var2) ); asm( "add r3,r2" : : ); asm( "mov.l r2, %0" : "=g"(var1) : );

Schau mal für den GCC 3.4.3 unter folgender Addresse nach

formatting link

Dort ist ne Beschreibung über die asm Anweisung

Generell würde ich dann den Codeteil entweder in ein Makro packen oder in ne inline Funktion oder ähnliches, damit dein Gesamtcode einfacher auf ne andere Architektur portiert werden kann.

tschaule Martin

Reply to
Martin Kaul

Hint: oder mit -O0 übersetzen...

tschaule Martin

Reply to
Martin Kaul

Martin Kaul schrieb:

Das ist ziemlich das Unsinnigste, was man tun kann: man hat hinterher etwas komplett anderes vorliegen. Ob da das gewünschte NEG drin vorkommt, mag ich bezweifeln. In jedem Falle ist es so sehr verschieden vom endgültigen Code (falls man nicht gerade gewillt ist, die fertige Applikation auch ohne Optimierung tuckern zu lassen), dass ich generell jedem raten würde, lieber mit den Skurrilitäten eines Optimierers (und dem Debuggen optimierten Codes) zurechtkommen zu lernen.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc
Reply to
Joerg Wunsch

Das kommt darauf an - wenn ich die Logik des Programmes debuggen will, dann übersetzt ich immer mit -O0, da ansonsten der Programmablauf beim Steppen ziemlich gewöhnungsbedürftig ist.

Wenn ich was am Compiler rumprobiere dann übersetze ich auch immer mit

-O0, da ich dann die Anzahl der möglichen Seiteneffekte klein halte.

Natürlich wird dann am Ende mit der entgültigen Optimierungsstufe gegengecheckt.

tschaule Martin

Reply to
Martin Kaul

Martin Kaul schrieb:

Gewöhn' Dich aber besser dran, viele obskure Programmierfehler werden wirklich erst durch das radikale ,,Wegoptimieren'' des Optmizers richtig sichtbar.

C'mon, eine ,,echte'' RISC-CPU debuggt sich in dieser Hinsicht noch schwieriger. Ich erinnere mich an Motorola 88000 unter DG/UX, da sind Register-Operationen billiger und schneller als Speicher-Operationen, folglich schachtelt der Compiler nach Möglichkeit beide ineinander. Ein single step durch einen Funktionsaufruf springt dann abwechselnd zwischen den Zeilen vor der Funktion und der Zeile mit der Funktion hin und her... auch daran konnte man sich gewöhnen.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
				Kristian Köhntopp, de.comp.os.unix.misc
Reply to
Joerg Wunsch

Ist wahrscheinlich Geschmackssache - ich habe in dieser Hinsicht noch keine Probleme gehabt. Liegt vielleicht auch daran, dass der Code mit PC-Lint geprüft wird - viele Programmierfehler was man schnell mal in den Code schreibt werden damit sowieso ausgefiltert.

tschaule Martin

Reply to
Martin Kaul

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.