Assembler in C Projekt, Integrationsprobleme

[Leo B. (luigi)]

Hallo zusammen,

ich habe ein kleines Problem meinen Assembler-Code in ein C-Projekt zu 
integrieren/kombinieren.
Mein erstes Problem ist es, Konstanten aus einem C-Header im 
Assembler-File zu nutzen.
Viele Konstanten (speziell Speicheradressen, aber auch andere) sind in 
dem Schema "0x10000000U" definiert. Dabei macht das "U" im 
Assembler-file große Probleme, da es im Assemblercode nicht richtig 
interpretiert (gerne auch ignoriert) wird und Fehler wirft.

Falls mir hier jemand Ideen geben kann, wie ich das bewerkstelligen kann 
ohne die "U"s alle aus meinen Headern zu entfernen, fände ich das sehr 
schön.

Kleines Beispiel:
-----------------
header.h

...
#define MYADDR 0x10000800
...

-----------------
asm.S

...
LDR  R1, =MYADDR
...

-----------------


Vielen Dank
Leo


PS: Meine Umgebung:
Ich arbeite aktuell im CooCox CoIDE für einen STM32F4.
Ziel soll aber idealerweise Compiler-/Enwicklungsumgebungs-unabhängig 
und für alle möglichen STM32F[0-4] brauchbaren code zu erzeugen.

[Clemens L. (c_l)]

Benutze UINT32_C aus <stdint.h>, und definiere es entsprechend für den 
Assembler.

[Leo B. (luigi)]

Vielen dank für die Antwort.

Wie wichtig ist denn eigentlich diese Typendefinition bei Defines?
Ich habe mir angewöhnt sie zu machen, aber können Berechnungsfehler 
auftreten, wenn man sie nicht macht?
Ich finde gerade dazu nicht sehr viel.

Vielen Dank nochmal,
Leo

[Yalu X. (yalu) (Moderator)]

Leo B. schrieb:
> Viele Konstanten (speziell Speicheradressen, aber auch andere) sind in
> dem Schema "0x10000000U" definiert.

Folgendes wird vom GNU-Assembler akzeptiert, auch wenn die Verwendung
der Suffixe L, U, UL usw. für Integer-Konstanten nicht dokumentiert zu
sein scheint:

#define MYADDR 0x10000800U

LDR  R1, =MYADDR

> Ziel soll aber idealerweise Compiler-/Enwicklungsumgebungs-unabhängig
> und für alle möglichen STM32F[0-4] brauchbaren code zu erzeugen.

Beim C-Compiler ist das kein so großes Problem, weil die C-Syntax
genormt ist. Beim Assembler kocht aber i.Allg. jeder Hersteller sein
eigenes Süppchen.

[Leo B. (luigi)]

Yalu X. schrieb:
> Folgendes wird vom GNU-Assembler akzeptiert, auch wenn die Verwendung
> der Suffixe L, U, UL usw. für Integer-Konstanten nicht dokumentiert zu
> sein scheint:
>
> --------------------------
> #define MYADDR 0x10000800U
>
> LDR  R1, =MYADDR
> --------------------------

Leider widerspricht da mein Compiler:

Error: garbage following instruction -- `ldr R1,=0x10000800U'

[Amateur (Gast)]

Wenn Du die Typen richtig definierst, können keine Fehler entstehen. 
Außer den selbstgemachten Fehler (z.B. Überläufe).
Was aber passieren kann, wenn Du defaults verwendest, ist, es wird die 
falsche Voreinstellung verwendet. Z.B. default unsigned und verwendet 
signed ("Wenn ich den Erwische, der mir ein Bit Datenbreite geklaut 
hat..."). Oder so Späßchen wie 2 + 224 = -30.

[Amateur (Gast)]

>Error: garbage following instruction -- `ldr R1,=0x10000800U'
Versuch's mal ohne "U". Ich kenne aber den Compiler/Prozessor nicht.

[Yalu X. (yalu) (Moderator)]

Leo B. schrieb:
> Leider widerspricht da mein Compiler:
>  Error: garbage following instruction -- `ldr R1,=0x10000800U'

Hmm, meiner bringt diese Fehlermeldung nur dann, wenn ich einen auch in
C ungültigen Suffix, bspw. "K", an die Zahl anhänge:

Error: garbage following instruction -- `ldr R1,=0x10000800K'

Vielleicht sind diese Integer-Suffixe ein neueres Feature von GAS. Ich
habe hier die Version 2.28.

Edit:

Hier wurde der U-Suffix eingeführt:

  https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=e140100a5da85568e83ffe8e77d3f5e4a59ddee8

Die Änderung ist seit Version 2.27 vom August 2016 offziell. Seit
Version 2.28 vom März 2017 ist auch der L-Suffix erlaubt.

[Peter D. (peda)]

Eine gebräuchliche Methode ist, sich einfach in C eine Dummyfunktion mit 
allen Variablen, Argumenten und Returnwerten zu schreiben und die nach 
Assembler übersetzen zu lassen. Da kann man dann einfach den gewünschten 
Assemblercode einfügen.