[ASM] VS.NET en inline ASM, wat wel en niet

[Verwijderd]

Ik ben bezig een aantal stukken C++ code om te bouwen naar inline assembly met Visual Studio.NET.

Nu vindt ik de documentatie over inline assembly binnen Visual Studio niet echt goed, of compleet. Ik heb een heleboel voorbeeld programma's gevonden op het net, maar geen van die programma's willen compilen in Visual Studio. Ik krijg altijd wel opcode/syntactische foutmeldingen.

Ik vraag mij dus af welke (syntactische) variant van assembly ik kan gebruiken. Ik ben begonnen aan de Intel IA-32 documentatie, alleen ik zou er graag een aantal voorbeeld programma's bij hebben. Deze kan ik dus nergens vinden (iig. geen voorbeeldjes die daadwerkelijk runnen als ik ze inline gebruik).

MS zegt dat MASM gebruikt kan worden, maar voor zover ik weet niet inline. Een aantal links op got verwijzen naar: http://cs.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html maar de voorbeeldjes in dat boek werken ook niet.

Als ik mij puur houd aan de opcodes gegeven in de documentatie van Intel dan pakt de compiler het wel zonder fouten, ik denk alleen dat het dan onnodig lang duurt voordat ik op gang ben.

De losse statements werken wel, dus de MOV EAX, EBX etc, maar het is meer de uitgebreidere control structures die overal in tutorials worden gebruikt, maar die de inline assembler dus niet snapt.

Dus ik ben op zoek naar tutorials/samples/boeken(?) die assembly code hanteren die de inline assembler van Visual Studio.NET kan gebruiken...

[GrimaceODespair]

Niet dat ik je enorm veel kan helpen ofzo, maar om de anderen te snel af te zijn: welke foutmeldingen krijg je dan precies op welke voorbeelden?

[Verwijderd]

Dit is een van de voorbeeld progjes van de eerder genoemde link:

code:

dseg            segment para public 'data'

character       byte    ?
UnsignedIntVar  word    ?
DblUnsignedVar  dword   ?

integer         typedef sword
char            typedef byte
FarPtr          typedef dword

J               integer ?
c1              char    ?
PtrVar          FarPtr  ?

K               integer 4
c2              char    'A'
PtrVar2         FarPtr  L

L               integer 0, 1, 2, 3
c3              char    'A', 0dh, 0ah, 0
PtrTbl          FarPtr  J, K, L

string          byte

dseg            ends

Daar maakt VS dit van:

code:

error C2400: inline assembler syntax error in 'opcode'; found 'ends'
warning C4101: 'var2' : unreferenced local variable
error C2400: inline assembler syntax error in 'opcode'; found 'segment'
error C2400: inline assembler syntax error in 'opcode'; found 'byte'
warning C4405: 'byte' : identifier is reserved word
error C2400: inline assembler syntax error in 'opcode'; found 'word'
warning C4405: 'word' : identifier is reserved word
error C2400: inline assembler syntax error in 'opcode'; found 'dword'
warning C4405: 'dword' : identifier is reserved word
error C2400: inline assembler syntax error in 'opcode'; found 'typedef'
error C2400: inline assembler syntax error in 'opcode'; found 'data type'
error C2400: inline assembler syntax error in 'opcode'; found 'typedef'
error C2400: inline assembler syntax error in 'opcode'; found 'integer'
error C2400: inline assembler syntax error in 'opcode'; found 'data type'
error C2400: inline assembler syntax error in 'opcode'; found 'FarPtr'
error C2400: inline assembler syntax error in 'opcode'; found 'integer'
error C2400: inline assembler syntax error in 'opcode'; found 'data type'
error C2400: inline assembler syntax error in 'opcode'; found 'FarPtr'
error C2400: inline assembler syntax error in 'opcode'; found 'integer'
error C2400: inline assembler syntax error in 'opcode'; found 'data type'
error C2400: inline assembler syntax error in 'opcode'; found 'FarPtr'
error C2400: inline assembler syntax error in 'opcode'; found 'byte'
warning C4405: 'byte' : identifier is reserved word

Het lijkt mij dat ook dit een van de 'hogere' assembly's is, terwijl ik deze link gevonden heb bij een uitleg/vraag over inline assembly.

[madwizard]

De inline assembler syntax van visual studio is wel MASM syntax te noemen, maar lang niet alle features van MASM worden ook ondersteund door de inline assembler. De code die je noemde bijvoorbeeld, een data segment definieren is natuurlijk niet erg 'inline'. Sterker nog, geen enkele regel van dat stuk code zal omgezet worden in code, het is alleen data.

Inline assembler is bedoeld voor simpele stukjes code, als je serieus stukken assembler wilt combineren met C(++) kun je beter een losse assembler gebruiken en daarna de output aan elkaar linken. MASM kun je prima gebruiken met visual C.

[Verwijderd]

Wat ik er uiteindelijk mee wil gaan doen:

Ik heb een bitmap plaatje, in grijstinten. Deze wil ik per grijstint omzetten in een andere kleur.

Dit probeer ik sneller te krijgen door het omzetten van de bytes naar de nieuwe bytes in inline ASM te doen.

Maar dat is slechts een voorbeeld... Ik wil me naast dit specifieke geval zowieso verdiepen in ASM om meer inzicht te krijgen in algoritmes om deze zo efficienter te maken.

[madwizard]

Ook voor de optimalisatie is het beter hele functies in assembler te schrijven dan met inline stukjes te gaan werken. De C++ compiler kan namelijk weinig meer met je assembler code kunnen dan het gewoon overnemen, en zal z'n eigen code er dus omheen moeten optimaliseren. Keuzes die jij maakt om je assembler stukje zo snel mogelijk te maken kunnen dan in de weg zitten van de keuzes die de compiler zou willen maken om de rest van de code optimaal te krijgen. Dus maak of een hele functie in assembler, of helemaal in C++. Inline combineren is vaak alleen maar slechter voor de performance.

Op m'n site staat een beginnerstutorial voor win32asm (assembler in 32-bit windows), je kunt die lezen om een beetje wijs te worden in assembler. Art of Assembly is ook goed. Maar let wel dat je echt wel flink wat van assembler en de CPU architectuur moet weten wil je snellere code dan je C++ compiler kunnen schrijven. Vaak denken mensen assember = snel maar dat hangt maar helemaal van de programmeur af.

Op www.movsd.com kun je het MASM32 pakket downloaden, een pakket met MASM, een berg andere tools en de windows includes en libraries voor MASM. Het pakket is voornamelijk bedoeld voor programma's die helemaal in assembler gemaakt worden maar kan prima gebruikt worden om in combinatie met C++ gebruikt te worden. De masm versie (ml.exe) die bij VC zit is trouwens nieuwer dan in het MASM32 pakket (7 tegen 6), omdat die in het MASM32 pakket de laatste versie is die nog 'vrij' gedistribueerd mocht worden.

[.oisyn]

madwizard schreef op 14 juni 2004 @ 10:49:
Ook voor de optimalisatie is het beter hele functies in assembler te schrijven dan met inline stukjes te gaan werken. De C++ compiler kan namelijk weinig meer met je assembler code kunnen dan het gewoon overnemen, en zal z'n eigen code er dus omheen moeten optimaliseren. Keuzes die jij maakt om je assembler stukje zo snel mogelijk te maken kunnen dan in de weg zitten van de keuzes die de compiler zou willen maken om de rest van de code optimaal te krijgen. Dus maak of een hele functie in assembler, of helemaal in C++. Inline combineren is vaak alleen maar slechter voor de performance.

En wat is dan het voordeel van een aparte assembler gebruiken? Al die dingen die jij noemt zijn in dat geval precies zo.

Oh, ik bedenk me trouwens ineens dat je "inline" misschien verkeerd opvat. Met inline assembly wordt bedoeld dat je gebruik maakt van het asm keyword om assembly code in een C++ source file te gebruiken. Het heeft verder niets te maken met het "inline" keyword van C++.

Maar inline assembly is wel goed te gebruiken in inner loops, voor als je bijvoorbeeld van 3dnow! of SSE instructies gebruik wilt maken. De compiler weet welke registers worden gemodificeerd door je asm code en zal z'n optimalisaties daaraan proberen aan te passen (en als je niet weet wat je doet kan het idd wel een enorm nadelig effect hebben). Aan de andere kant kent VC++ 7.1 (7.0 geloof ik ook, weet ik niet zeker) intrinsics om variabelen te alloceren als mmx registers en speciale functies om deze te bewerken, dus wellicht is inline asm dan ook niet wat je wilt omdat je met die functies hetzelfde kan, plus dat de compiler beter begrijpt wat je probeert te doen (en zelf de controle heeft over welke registers gebruikt worden)

[madwizard]

.oisyn schreef op 14 juni 2004 @ 23:52:
En wat is dan het voordeel van een aparte assembler gebruiken? Al die dingen die jij noemt zijn in dat geval precies zo.

Oh, ik bedenk me trouwens ineens dat je "inline" misschien verkeerd opvat. Met inline assembly wordt bedoeld dat je gebruik maakt van het asm keyword om assembly code in een C++ source file te gebruiken. Het heeft verder niets te maken met het "inline" keyword van C++.

Nee dat is niet wat ik bedoel, ik bedoel wel degelijk de _asm blocks. Maar mijn post is idd niet helemaal duidelijk. Wat ik eigenlijk bedoelde is dat mensen vaak een paar regels omzetten in inline assembler (denk aan een swap met 3x xor), wat dus heel weinig zin heeft voor de performance omdat de compiler daar juist alleen maar omheen moet werken. De juiste optimalisaties zijn vaak enorm afhankelijk van de context (loops, register en geheugengebruik, wat staat er in de cache), en als je C++ en assembler gaat combineren is deze context gedeeltelijk onbekend omdat je nooit weet wat de optimizer doet met de C++ code.

Vandaar dat ik zei dat je een op zich staande functie beter helemaal in assembler kunt schrijven dan kunt mixen met C++. Maar ik had misschien iets genuanceerder moeten zijn, want het is niet altijd erg. Een voorbeeld gaf je zelf al en er zijn vast meer voorbeelden te bedenken. Het ging er mij meer om dat het stukje inline assembler wel zinnig genoeg moet zijn om niet puur in de weg te zitten. Het idee dat K-Mile noemde bijvoorbeeld: het omzetten van de grijswaarden-bytes naar nieuwe bytes zou ik niet in inline assembler doen. Het is gewoon een te klein detail. Je kunt wel de hele loop of het hele omzetten in assembler doen, dat heeft volgens mij veel meer zin dan alleen het byte-omzetten.

Los van dit alles heb je in losse assembler files alle mogelijkheden van de assembler tot je beschikking, tegen slechts de subset die je hebt met inline assembler. Maar natuurlijk hangt ook dit weer van je bedoelingen af, misschien heb je dit helemaal niet nodig.

[.oisyn]

Ah ok, dan zijn we het eens

Ik zou het probleem met de bitmap ook niet in asm implementeren idd. De code daarvoor is te triviaal, een C++ compiler kan dat prima zelf