PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Inline Assembler - Porting von MSVC nach GCC?


zeckensack
2002-08-25, 08:52:53
Scheint ja höllisch kompliziert zu sein ... allgemeine Empfehlung bis jetzt, war einfach den NASM zu nehmen, damit libs zu erzeugen und dazuzubinden.

Das schmeckt mir aus mehreren Gründen nicht:
1a)Ich will mich nicht mit calling conventions rumärgern, das Projekt ist schon unübersichtlich genug
1b)Ich hätte das ganze gerne typsicher
2)Ich hätte gerne den C-Präprozessor davor, um MMX und MMX+MOVNTQ-Code aus dem gleichen Source erzeugen zu können
3)Ich nutze C++ Namespaces

Auf 'richtige' ASM-Funktionen kann ich ganz gut verzichten.

Ich habe im Moment 45kByte (!!) Quellcode mit Funktionen, die größtenteils aus Inline-Assembler bestehen. Der lässt sich in der aktuellen Form allerdings nur unter VC vernünftig kompilieren.

Was ich gerne hätte, wäre zumindest erstmal eine vernünftige Anleitung zum Inline-Assembler (GCC-Manpages geben nichts her), um selber Hand anlegen zu können.

Am allerbesten gleich ein fertiges Tool, das automatisch konvertieren kann :)

Das sieht bei mir zB so aus:Irgendwo im C++-Code ...
#define STOREQWORD MOVQ
#define END_STORE //warning killer
namespace MMX
{
#include "cc_texture_stuff.i"
....
}

#undef STOREQWORD
#undef END_STORE
#define STOREQWORD MOVNTQ
#define END_STORE SFENCE
namespace eMMX
{
#include "cc_texture_stuff.i"
....
}
cc_texture_stuff.i
void
decode_paletted_rgb(void* const target,const void*const source,const void*const palette,uint pixels)
{
if (pixels==0) return;
__asm
{
PUSH EBP
MOVQ mm7,c4_8888 //we set alpha to full for all output pixels
MOV ESI,source
MOV EDI,target
MOV ECX,pixels
MOV EBX,ECX
MOV EBP,palette //warning: local vars are gone now!

AND ECX,0xFFFFFFF8 //decode eight pixels per iteration
JZ pre_loop_1
ADD ESI,ECX //input is one byte per pixel
LEA EDI,[EDI+4*ECX] //output is four bytes per pixel
SHR ECX,1
NEG ECX
loop_8:
MOV EDX,[ESI+2*ECX]
MOVZX EAX,DL
MOVD mm0,[EBP+4*EAX]
MOVZX EAX,DH
PUNPCKLDQ mm0,[EBP+4*EAX]
SHR EDX,16
MOVZX EAX,DL
MOVD mm1,[EBP+4*EAX]
MOVZX EAX,DH
PUNPCKLDQ mm1,[EBP+4*EAX]

POR mm0,mm7
POR mm1,mm7

MOV EDX,[ESI+2*ECX+4]
MOVZX EAX,DL
MOVD mm2,[EBP+4*EAX]
MOVZX EAX,DH
PUNPCKLDQ mm2,[EBP+4*EAX]
SHR EDX,16
MOVZX EAX,DL
MOVD mm3,[EBP+4*EAX]
MOVZX EAX,DH
PUNPCKLDQ mm3,[EBP+4*EAX]

POR mm2,mm7
POR mm3,mm7

STOREQWORD [EDI+8*ECX],mm0
STOREQWORD [EDI+8*ECX+8],mm1
STOREQWORD [EDI+8*ECX+16],mm2
STOREQWORD [EDI+8*ECX+24],mm3

ADD ECX,4
JNZ loop_8
pre_loop_1:
AND EBX,7
JZ finished
ADD ESI,EBX
LEA EDI,[EDI+4*EBX]
NEG EBX
MOVD EDX,mm7
loop_1:
MOVZX EAX,BYTE PTR [ESI+EBX]
MOV ECX,[EBP+4*EAX]
OR ECX,EDX
MOV [EDI+4*EBX],ECX

INC EBX
JNZ loop_1
finished:
END_STORE
EMMS
POP EBP
}
}

Brauche also folgendes:
Zugriff auf die Funktionsparameter (definiert mittels ordentlicher C-Prototypen)
Maximal ein C-Statement pro Funktion
Und dann haufenweise ASM (genaue Syntax in GCC ???)

Und wie gesagt, von der Sorte habe ich reichlich, wäre also am schönsten, das irgendwie automatisieren zu können, ich will nämlich weg von VC, weit weit weg =)

Exxtreme
2002-08-25, 09:13:15
Originally posted by zeckensack

Und wie gesagt, von der Sorte habe ich reichlich, wäre also am schönsten, das irgendwie automatisieren zu können, ich will nämlich weg von VC, weit weit weg =)
Beim obigen Problem kann ich dir leider nicht helfen da ich noch nie was mit Inline-ASM gemacht habe.

Warum willst du weg von VC++? Ich dachte, die Entwicklungsumgebung wäre gut?

Gruß
Alex

zeckensack
2002-08-25, 09:35:40
Originally posted by Exxtreme
Warum willst du weg von VC++? Ich dachte, die Entwicklungsumgebung wäre gut?

Gruß
Alex Ist sie auch. Hat Spaß gemacht, solange es keine Alternativen gab. DevCC ( http://www.bloodshed.net/ ) wird aber langsam besser und ist kostenlos, sodaß sich das Mitgehen mit MS' Lizenz- und Upgradepolitik nicht mehr lohnt.

IMHO ist der GCC auch der wesentlich bessere Compiler, vor allem optimiert er deutlich besser und erzeugt kompakteren Code - solange man mit MSVC6+SP5 vergleicht.

Es gibt natürlich eine neuere Version von MS, die kostet aber diesmal selbst als Upgrade knapp tausend Flocken und 'braucht' ein OS-Upgrade und die .NET-Runtime und hassenichgesehen. Das kann mir erstmal gestohlen bleiben, vor allem natürlich wegen der Kohle :|

Xmas
2002-08-25, 14:20:54
Oje, das kann in viel Arbeit ausarten...

Hier mal etwas zum Unterschied zwischen Intel- und AT&T-Syntax:
http://www.delorie.com/djgpp/faq/converting/asm.html

Ich glaub ich hab mal was zu nem automatischen Konverter gelesen, weiß aber nicht mehr wo...

edit:
http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/
ftp://x2ftp.oulu.fi/pub/msdos/programming/convert/ta2asv08.zip

Nasenbaer
2002-08-25, 14:24:16
Originally posted by zeckensack
Ist sie auch. Hat Spaß gemacht, solange es keine Alternativen gab. DevCC ( http://www.bloodshed.net/ ) wird aber langsam besser und ist kostenlos, sodaß sich das Mitgehen mit MS' Lizenz- und Upgradepolitik nicht mehr lohnt.


Wie sieht das mit dem Debugger dort aus?

Bei Prob kann ich dir leider auch nicht helfen da ich noch kein Stück Assembler kann. Hängt noch in der Warteschleife. :]

MFg Nasenbaer

vogel
2002-09-12, 18:29:08
Intel's C++ Compiler fuer Linux unterstuetzt das "Intel" format fuer inline assembly (welch Ueberraschung ;)) und ist sehr kompatibel mit MSVC.

-- Daniel

vogel
2002-09-12, 18:57:45
Originally posted by zeckensack
IMHO ist der GCC auch der wesentlich bessere Compiler, vor allem optimiert er deutlich besser und erzeugt kompakteren Code - solange man mit MSVC6+SP5 vergleicht.

Nicht fuer uns. Okay, mittlerweile benutzen wir VS.NET aber schon mit VC6 hat Microsoft's Compiler jede Version von gcc im Regen stehen lassen.

Ryan hat eine sehr sehr lange Liste was alles kaputt ist mit gcc/ GNU toolchain unter Linux und was einfach funktioniert unter Windows.

Die Kurzzusammenfassung: "gcc blows!" :)

-- Daniel, Epic Games Inc.

Nasenbaer
2002-09-12, 19:57:40
Originally posted by vogel

Nicht fuer uns. Okay, mittlerweile benutzen wir VS.NET aber schon mit VC6 hat Microsoft's Compiler jede Version von gcc im Regen stehen lassen.

Ryan hat eine sehr sehr lange Liste was alles kaputt ist mit gcc/ GNU toolchain unter Linux und was einfach funktioniert unter Windows.

Die Kurzzusammenfassung: "gcc blows!" :)

-- Daniel, Epic Games Inc.

Du meinst der gcc ist wesentlich schlechter als der integrierte in VS.Net und VC++6???
Sollte das stimmen hasr du soeben mein gesamtes Weltbild zerstört. :/
Ich dachte immer er wäre wesentlich ANSI-konformer, optimiert besser usw.

Mfg Nasenbaer

Demirug
2002-09-12, 20:12:53
wie gut der gcc auf der x86 platform ist kann ich nicht sagen. aber ein PS2 Entwickler (im Entwicklerpacket von Sony ist auch ein gcc) hat sich bitterböse darüber beschwert wie schlecht das Teil optimiert. Am ende müsse man jedesmal zwischen 25 und 50% des Codes in Assembler schreiben um im ersten Frame zu laufen.

Wuzel
2002-09-12, 20:23:42
Also der Gnu Compi funzt nur mit AT&T ASM ( Inline, mit den GNU eigenen tools ) vernünftig, kann ich 100% bestätigen. Es gibt da einige Sachen wie *edit*/Link putt/*edit* mit denen ich unter Lin zwar guten Inline NASM bekamm, aber naja ....

Unter Win ist da wohl der Intel Compi diesbezüglich die einzige MS Compi alternative, die auch was kann.
Hmm, muss mal Kramen, gab da noch sowas, schreibe wenn ichs hab den link hin.

vogel
2002-09-13, 08:30:33
Originally posted by Nasenbaer
Du meinst der gcc ist wesentlich schlechter als der integrierte in VS.Net und VC++6???
Weitaus schlechter, weitaus langsamer.

Fuer einen vollen rebuild unserer Codebase braucht VS.NET 5 min und gcc 2.9.3 1 Stunde! Da ueberlegt man sich zweimal ob man unter Linux 'nen Header anfasst!

-- Daniel, Epic Games Inc.

Exxtreme
2002-09-13, 08:37:56
Naja, vom GCC habe ich auch noch nie was Positives gehört und ich verfolge die Sache. Die sind irgendwie ständig am Murksen. Die ändern unter Linux immer wieder das "Binärformat", so daß eine neue Version inkompatibel zu den alten Versionen ist und man darf dann alle Libs nochmal neu kompilieren. Deswegen benutzen viele Entwickler unter Linux noch die Version 2.96 obwohl es schon Versionen 3.x gibt. Also ich würde doch eher die Compiler von Intel, Micros~1 oder Borland nehmen.

Gruß
Alex