unterschied "reti" und " reti"

[andi (Gast)]

hi,
Frage steht im thread, ersteres funktioniert.
" push" oder " pop" geht zum Beispiel nur mit dem Leerzeichen?

[Daniel H. (Firma: keine) (commander)]

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

[Tux (Gast)]

Es ist Wochenende, was erwartest du?

[Magnus M. (magnetus)]

EinnormalerSatzliestsichohneLeerzeichenjaauchnursauschwer.Warumsollteder 
AssemblerohneLeerzeichenauskommen?

[µC (Gast)]

Bei mir geht push/pop auch ohne Leerzeichen, reti kennt mein µC nicht.

[Magnus M. (magnetus)]

Uups...habgeradegesehendassDuesjaanderherumgemeinthast...

[Daniel H. (Firma: keine) (commander)]

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

Multiple markers at this line
  - pop cannot be resolved to a type
  - Syntax error on token ";", delete 
   this token

Multiple markers at this line
  - push cannot be resolved to a type
  - Syntax error on token ";", delete 
   this token

[andi (Gast)]

  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");

[Rufus Τ. F. (rufus)]

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:

 pop r15
 pop r14
 ...
 pop r4
reti

Wird's klar?

[Paul B. (paul_baumann)]

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

[andi (Gast)]

Rufus Τ. Firefly schrieb:
> Einfach: Assembler-Instruktionen dürfen nicht in der ersten
> Textspalte

Glaub ich dir mal so

> stehen. Da dürfen nur Labels o.ä. stehen.
>
> Schreib mal den ganzen Kram (der in den Anführungszeichen steht) in eine
> eigene Textdatei:
>  pop r15
>  pop r14
>  ...
>  pop r4
> reti
>

dann ist das Leerzeichen meines Erachtens unnötig? oder soll das irgend 
einen Anweisungsblock darstellen wie {} ? Also unnötig im sinne von \n 
ist vorhanden

> Wird's klar?

[Georg (Gast)]

Hallo,

zu unterschied "reti" und " reti": das ist der gleiche wie zwischen x 
und x.

Genug für den Troll.

Georg

[Noch einer (Gast)]

> Einfach: Assembler-Instruktionen dürfen nicht in der ersten Textspalte
> stehen.

Nanu? reti ist doch eine ganz normale Instruktion genau wie pop. Ein 
reti kann auch ein Label haben. Trotzdem geht es ohne Leerzeichen?

[Johann L. (gjlayde)]

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.

[Bernd K. (prof7bit)]

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.

[andi (Gast)]

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

gibts sowas für den msp430 auch?

[Johann L. (gjlayde)]

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.

#define STRINGIFY_(a) #a
#define STRINGIFY(a) STRINGIFY_(a)
#define THREE 3

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

___________________________________________________________

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:
 

#define THREE 3

  __asm__ ("ldi  r20, %[drei]" "\n\t"
           "ldi  r21, 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:

    __asm__(
      "sbic  %[_PIND], 6 \n\t"
      :
      : [_PIND]    "I"  (_SFR_IO_ADDR(PIND))
    );

___________________________________________________________

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:

    __asm__ ("sbic  %i[pind], 6"
             :: [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