Inline Asm -> standard konform?
-
Hi,
ist inline Asm ala:cout << "foo" << endl; __asm // oder _asm?! { add x, 10 shr x, 1 } cout << x << endl;
standard konform?!
Wenn nicht ist ees wenigstens halbwegs Platform unabhängig? sprich: läuft es auf allen x86 (wenn man keine Speziellen Opcodes (MMX, o.ä.) benutzt)?Hilfe
ZR
-
Nein, ist es nicht. Funktioniert nur mit VC und vielleicht ein paar anderen Compilern. Standardkonform ist folgende Syntax:
asm("...");
Es ist aber implementierungsspezifisch wie die Informationen an Assembler weitergegeben werden, das heißt auch der Inhalt des String-Literals.
-
Es kann nicht standardkonform sein, wenn es selbst auf verschiedenen Prozessoren unterschiedliche Ergebnisse liefert!
-
ganz übel finde ich diese at&t notation, die der gcc verwendet
-
MisterZ schrieb:
Es kann nicht standardkonform sein, wenn es selbst auf verschiedenen Prozessoren unterschiedliche Ergebnisse liefert!
Quark. Der C++ Standard definiert nicht welche Assembler-Befehle vom asm-declarator verwendet werden können. Es ist die Aufgabe des Programmierers, sich um den platformspezifischen Assembler-Code zu kümmern und nicht der C++ Sprache.
-
Der Standard sagt lediglich folgendes:
asm ( stringliteral ) ;
Also Schlüsselwort asm und nicht __asm, _asm oder ähnliches. Da sich selbst daran nicht alle Compiler halten, muss man Assembler grundsätzlich als unportabel einstufen.
Dennoch verbietet dir niemand inline Assembler zu benutzen. Grundsätzlich haben sich die Intel und AT&T Syntax durchgesetzt. Hast du zB den MSC oder GCC, empfiehlt sich die Intel Syntax, da dies beide können (auch wenn ichs beim GCC noch nie ausprobiert hab).
Willst du das ganze relativ portabel haben, könntest du es zB so machen:#if defined(COMPILER_1) || defined(COMPILER_2) // || welcher Compiler auch immer #define ASM_SYNTAX_INTEL #elif defined(COMPILER_3) || defined(COMPILER_4) // || siehe oben #define ASM_SYNTAX_ATT #endif #if defined(ASM_SYNTAX_INTEL) // hier asm Code mit Intel Syntax rein #elif defined(ASM_SYNTAX_ATT) // hier asm Code mit AT&T Syntax rein #else #error Besorg dir nen anderen Compiler! #endif
btw:
[mod_frage]Wieso wird eigentlich defined nicht farblich hervorgehoben wie die anderen Präprozessor Direktiven (dito #error)?[/mod_frage]
-
[mod_frage]Wieso wird eigentlich defined nicht farblich hervorgehoben wie die anderen Präprozessor Direktiven?[/mod_frage]
#if und #error sind auch ganz schwarz
-
Shlo schrieb:
MisterZ schrieb:
Es kann nicht standardkonform sein, wenn es selbst auf verschiedenen Prozessoren unterschiedliche Ergebnisse liefert!
Quark. Der C++ Standard definiert nicht welche Assembler-Befehle vom asm-declarator verwendet werden können.
Eben
-
Irgendwer schrieb:
[mod_frage]Wieso wird eigentlich defined nicht farblich hervorgehoben wie die anderen Präprozessor Direktiven?[/mod_frage]
#if und #error sind auch ganz schwarz
Ich denke das hat den einfachen Grund, dass der Nutzen in keinem Verhältnis zum Aufwand steht.
-
MisterZ schrieb:
Shlo schrieb:
MisterZ schrieb:
Es kann nicht standardkonform sein, wenn es selbst auf verschiedenen Prozessoren unterschiedliche Ergebnisse liefert!
Quark. Der C++ Standard definiert nicht welche Assembler-Befehle vom asm-declarator verwendet werden können.
Eben
Das hat aber nichts mit der Standardkonformität zu tun.
-
Shlo schrieb:
Das hat aber nichts mit der Standardkonformität zu tun.
Schon, der Gedanke war eher der, dass etwas, was z.B. nur auf manchen Prozessoren läuft wohl eher nicht in den Standard aufgenommen wird. Da man ja mehr oder weniger die Prozessoren standardisieren müsste, was ja dank den unterschiedlichen Befehlssätzen dummerweise nicht möglich ist.
-
[OT @ MisterZ]
System() ist auch im Standard enthalten und erzeugt auch auf jedem System unterschiedliche Ergebnisse! (nach deiner Meinung also nicht Standardkonform?!)
C++ kümmert es nicht, was du ans System schickst, es ist lediglich eine Schnittstelle zum System. Gleiches gilt für asm, was eine Schnittstelle zu Assembler darstellt.Das was du meinst ist Portabilität. Die ist mit prozessorabhängigen Befehlen sicherlich nicht gegeben, aber darum gings auch garnicht.
[/OT @ MisterZ]