unterschied "reti" und " reti"

Man, du überschüttest uns hier aber auch mit Informationen...

EinnormalerSatzliestsichohneLeerzeichenjaauchnursauschwer.Warumsollteder 
AssemblerohneLeerzeichenauskommen?

Uups...habgeradegesehendassDuesjaanderherumgemeinthast...

Bei mir gehen " push" und " pop" gar nicht, da kommt die Meldung

1

Multiple markers at this line

2

  - pop cannot be resolved to a type

3

  - Syntax error on token ";", delete 

4

   this token

5

6

Multiple markers at this line

7

  - push cannot be resolved to a type

8

  - Syntax error on token ";", delete 

9

   this token

Einfach: Assembler-Instruktionen dürfen nicht in der ersten Textspalte 
stehen. Da dürfen nur Labels o.ä. stehen.

Schreib mal den ganzen Kram (der in den Anführungszeichen steht) in eine 
eigene Textdatei:

1

 pop r15

2

 pop r14

3

 ...

4

 pop r4

5

reti

Wird's klar?

andi schrieb:
> asm (  " pop r15\n"
>       " pop r14\n"
>       " pop r13\n"
>       " pop r12\n"
>       " pop r11\n"
>       " pop r10\n"
>       " pop r9\n"
>       " pop r8\n"
>       " pop r7\n"
>       " pop r6\n"
>       " pop r5\n"
>       " pop r4\n"
>     );
>   asm (  "reti");

Deinen Namen ANDI hättest Du auch noch mit unterbringen können, denn
damit bist Du der geborene Assemblerprogrammierer.

;-)
Rjmp
Paul

Rufus Τ. Firefly schrieb:
> Einfach: Assembler-Instruktionen dürfen nicht in der ersten Textspalte
> stehen. Da dürfen nur Labels o.ä. stehen.

Hä? Bei welchem Assembler?

Zumindest mitm GNU Assembler ist das kein Problem.

Das hier lesen und 2 Stunden einsinken lassen:
http://www.avrfreaks.net/forum/few-remarks-avr-gcc-inline-assembler

Nichts davon überspringen jedes Detail ist wichtig, eventuell mehrmals 
lesen.

Bernd K. schrieb:
> Das hier lesen und 2 Stunden einsinken lassen:
> http://www.avrfreaks.net/forum/few-remarks-avr-gcc-inline-assembler
>
> Nichts davon überspringen jedes Detail ist wichtig, eventuell mehrmals
> lesen.

Naja, maches kann man direkt versenken anstatt es absinken zu lassen :-)

wek
> Sometimes, if the number of asm parameters is exhausted, numeric
> constants can be stringified and then concatenated with the asm
> statements' string, e.g.

1

#define STRINGIFY_(a) #a

2

#define STRINGIFY(a) STRINGIFY_(a)

3

#define THREE 3

4

5

  __asm__ ("ldi  r20, " STRINGIFY(THREE) " \n\t"

6

           "ldi  r21, 5 \n\t"

7

  );

___________________________________________________________

Ich weiß jetzt nicht, was er mit "if the number of asm parameters is 
exhausted" meint.  Zwar kann man außer 0...9 keine anderen Zahlen hinter 
% verwenden, allerdings kann man dem Operanden schlicht und einfach 
einen Namen geben und das ganze Makro-Gefummel sein lassen.

Übrigens erzeugt das obige Beispiel Code, der mit der Registerverwendung 
von avr-gcc kollidiert.  Aber egal... lesbarer sieht das dann so aus:
 

1

#define THREE 3

2

3

  __asm__ ("ldi  r20, %[drei]" "\n\t"

4

           "ldi  r21, 5"

5

           :: [drei] "n" (THREE));

Natürlich gibt es auch Situationen, wo man etwas nicht per Argument 
übergeben kann, aber diese sind sehr selten.  Beispiel sind globale asm, 
die ja keine Argumente haben können.

Und diese String-Futschelei hat auch nichts direkt mit Inline-Assembler 
zu tun, diesen Ballast kann man also hintan stellen wenn man sich in 
Inline-Assembler reinstrampeln will.  Das ist ganz "normales" C / C++ 
und kann hier angewendet werden, weil Teile von Inline-Assembler eben 
statische Strings sind.

wek
> There is also a gotcha in the form of IO register names [...]
> These are defined with their "memory" address in mind,
> so if you intend to use them as IO (as parameter of instructions
> in, out, sbi/cbi, sbis/sbic), 0x20 has to be deduced, best
> through using a macro already defined for this purpose:

1

    __asm__(

2

      "sbic  %[_PIND], 6 \n\t"

3

      :

4

      : [_PIND]    "I"  (_SFR_IO_ADDR(PIND))

5

    );

___________________________________________________________

Ab avr-gcc 4.7 gibt es den Modifier "%i", der eine Adresse als 
I/O-Adresse ausgibt.  Damit schreibt sich dieses Beispiel — unter 
Vermeidung des reservierten Bezeichners "_PIND" — so:

1

    __asm__ ("sbic  %i[pind], 6"

2

             :: [pind] "n" (&PIND));

wek
> Typical "constant" constraints are "M" and "I".
> "X" is also an interesting and useful constraint,
> meaning "any operand whatsoever ;-)".

Contraints "M" und "I" werden in den Beispielen durchweg falsch 
verwendet; i.d.R. ist "n" die richtige Wahl.

Zu "X" ist nur eins zu sagen: Diese Constraint sollte man keinesfalls 
in Inline-Assembler verwenden!  Punkt.  Mehr braucht man sich dazu nicht 
zu merken.  Gleiches gilt übrigens auch für andere Constraints wie "p" 
oder "o".

GCC verwendet auch intern Constraints, und alle Constraints, die GCC 
kennt, sind auch in Inline-Assembler sichtbar.  Was aber nicht bedeutet, 
dass sie auf der Ebene korrekt oder sinnvoll nutzbar wären.

Für deutschsprachige Leser gibe es übrigens eine Einführung zu avr-gcc 
Inline-Assembler:

http://rn-wissen.de/wiki/index.php/Inline-Assembler_in_avr-gcc