Assembler in C Projekt, Integrationsprobleme

Leo B. #5046838
Lesenswert?
• ▲
▼ 
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
1
...

2
#define MYADDR 0x10000800

3
...

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

2
LDR  R1, =MYADDR

3
...


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


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.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Leo B. #5046896
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Yalu X. Moderator #5046900
Lesenswert?
• ▲
▼ 
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:


1
#define MYADDR 0x10000800U

2


3
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Leo B. #5046938
Lesenswert?
• ▲
▼ 
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:
1
Error: garbage following instruction -- `ldr R1,=0x10000800U'
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Amateur Gast #5047010
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Yalu X. Moderator #5047137
Lesenswert?
• ▲
▼ 
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:


1
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Beitrag #5070417 wurde von einem Moderator gelöscht.
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren