C++ von GCC nach MS
-
Dieser Thread wurde von Moderator/in pumuckl aus dem Forum C++ (auch C++0x) in das Forum Assembler verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Evtl. funktioniert sogar das:
long rol_(long value, int n) { __asm { mov eax, value mov cl, n rol eax, cl } }
-
Inline-Assemblercode vom gcc, den kannst du nach normal asm maschinenspezifischer subraumaufruf übersetzen (siehe Nobuo oder /rant/) oder eben nach inline-asm vom VC-Compiler.
Genaugenommen ist aber Inline-Asm vom gcc Bestandteil seiner Möglichkeiten, also irgendwie auch schon wieder unverschämt sowas ins Asm Forum zu schieben
-
nachtfeuer schrieb:
Inline-Assemblercode vom gcc, den kannst du nach normal asm maschinenspezifischer subraumaufruf übersetzen (siehe Nobuo oder /rant/) oder eben nach inline-asm vom VC-Compiler.
Genaugenommen ist aber Inline-Asm vom gcc Bestandteil seiner Möglichkeiten, also irgendwie auch schon wieder unverschämt sowas ins Asm Forum zu schiebenTroll-Alarm
-
Im gcc compiler kann man einstellen das man die Intel syntax benutzen kann oder gleich im code hier die 2 varianten:
Beim compilieren:
gcc -o intelinlined -masm=intel intelinlined.cIm Quelltext:
int a=100, b=200; asm ( ".intel_syntax noprefix;" "mov ax, %0;" "mov cx, %1;" :"=a"(a), "=a"(b); );
http://www.lowlevel.eu/wiki/Inline-Assembler_mit_GCC
http://www.lowlevel.eu/wiki/Assemblerhttp://msdn.microsoft.com/en-us/library/4ks26t93(v=vs.71).aspx
-
Anstatt so ner inline asm Geschichte wärs besser die entsprechenden intrinsics zu verwenden.
-
dot schrieb:
Anstatt so ner inline asm Geschichte wärs besser die entsprechenden intrinsics zu verwenden.
Vollste Zustimmung. Dann hat sogar der MSVC einen Plan davon, was im Assembly los ist (gibt ja keinen) und kann den dann vielleicht auch ein wenig optimieren (ansonsten behandelt MSVC __asm-Blöcke prinzipiell als Blackbox, was Optimierung des Restes der Funktion sowie inlining verhindert; und wenn inlining verhindert wird wird noch extrem viel anderes verhindert [constant folding/propagation, loop unrolling/splicing, reordering-Sachen etc.; viele Optimierungen werden erst durch vorhergegende Optimierungen ermöglicht, aber wenn es schon beim Inlining scheitert ...]). Beim gcc ist letzteres durch constraints+co weniger ein Problem.
OP: 64bit-MSVC hat keinen Inline-Assembler, falls du den benutzen solltest.
-
template<typename T> T ror(T x, int n) { return (x >> n) | (x << sizeof(x)*CHAR_BIT - n); }
entsprechend rol. Würde mich wundern, wenn der Optimizer das nicht erkennt.
-
rüdiger schrieb:
template<typename T> T ror(T x, int n) { return (x >> n) | (x << sizeof(x)*CHAR_BIT - n); }
entsprechend rol. Würde mich wundern, wenn der Optimizer das nicht erkennt.
Ich verstehe zwar die Funktion nicht, weil müde und keine Ahnung, wie die Priorität der Operatoren ist, aber ich finde, man muss damit aufpassen, weil wenn vorzeichenbehaftete Datentypen "geschiftet" werden, können unvorhergesehene Dinge geschehen und das bedeutet, Bugs die schwer bis gar nicht auffindbar sind
-
phreck schrieb:
OP: 64bit-MSVC hat keinen Inline-Assembler, falls du den benutzen solltest.
Schwachsinn, natürlich hat der Inline-asm.
-
http://msdn.microsoft.com/en-us/library/wbk4z78b(v=VS.80).aspx
http://msdn.microsoft.com/en-us/library/wbk4z78b(v=VS.90).aspx
http://msdn.microsoft.com/en-us/library/wbk4z78b(v=VS.100).aspx