I know that this might be a touchy subject, but I recently was getting into asm programing and after programing in C and C++ for windows, I notced that ASM windows programing looks very similar.
I mean, a majority of windows programing is just calling to windows API's anyway, and when I look at ASM source codes, thats all it seems to be.
What I am asking is not WHAT I should use, but when is using ASM approprate in games with the high efficencey compilers are, now adays.
Another questions is where can I get a nice easy to read document on MMX, 3Dnow and SSE without haveing to hunt them in intel's site and AMD? I have always wanted to do some asm programing using those new fangled instructions and now that I have the skill I want to see about blowing up my computer:P
I mean, a majority of windows programing is just calling to windows API's anyway, and when I look at ASM source codes, thats all it seems to be.
What I am asking is not WHAT I should use, but when is using ASM approprate in games with the high efficencey compilers are, now adays.
Another questions is where can I get a nice easy to read document on MMX, 3Dnow and SSE without haveing to hunt them in intel's site and AMD? I have always wanted to do some asm programing using those new fangled instructions and now that I have the skill I want to see about blowing up my computer:P
There would be no war unless it's on the crusades or algorithms section where people will criticize even a difference of 1 clock cycle or 1 byte. ;)
usually, I code all my d3d proggy in HLL... well sometimes the idea of classes and objects can be a good thing but I limit them to a small number, I don't go class crazy when it comes to games and restrict usage of assembly with mmx, sse to routines. You can check the algorithm section for optimized routines especially the ZeroMemory function. Which is mostly used.
I use Intel VTune for looking at bottlenecks. This is where I translate to assembly.
Sometimes we code apps that uses DX mostly for fun, there is no speed to be gained if we are just calling functions since calling functions in HLL and ASM are the same unless you do some tricky usage of the stack.
Of course, we love to share the tricks if you'll ask. ;)
There are links posted on the board about mmx and sse. Try searching, you'll find a acouple of hits. :)
usually, I code all my d3d proggy in HLL... well sometimes the idea of classes and objects can be a good thing but I limit them to a small number, I don't go class crazy when it comes to games and restrict usage of assembly with mmx, sse to routines. You can check the algorithm section for optimized routines especially the ZeroMemory function. Which is mostly used.
I use Intel VTune for looking at bottlenecks. This is where I translate to assembly.
Sometimes we code apps that uses DX mostly for fun, there is no speed to be gained if we are just calling functions since calling functions in HLL and ASM are the same unless you do some tricky usage of the stack.
Of course, we love to share the tricks if you'll ask. ;)
There are links posted on the board about mmx and sse. Try searching, you'll find a acouple of hits. :)
Hi WarlockD,
I did DirectX in C, in C++, in asm and even in C++ with inline asm. :grin:
Example:
You should use whatever you feel comfortable with.. from your description perhaps it may be better to start learning asm by inlining it in your C++ programs, and then some day decide to do the big step and do all in asm (if you'll feel it productive or convenient, or just fun).
About the other question, you find an MMX tutorial at: http://docs.tommesani.com/
I did DirectX in C, in C++, in asm and even in C++ with inline asm. :grin:
Example:
void DirectDraw_VerticalBlank_Wait(U32 Device,U32 Flags) {
if (DirectDraw[Device].CooperativeLevel==0) {
DirectDraw_SetCooperativeLevel_Normal(Device);
}
// -- WaitForVerticalBlank
P32 interfacept=DirectDraw[Device].Interface.Pt;
asm {
PUSH 0
PUSH [Flags]
MOV EAX,[interfacept]
PUSH EAX
MOV EAX,[EAX]
CALL [EAX+WaitForVerticalBlank]
}
}
You should use whatever you feel comfortable with.. from your description perhaps it may be better to start learning asm by inlining it in your C++ programs, and then some day decide to do the big step and do all in asm (if you'll feel it productive or convenient, or just fun).
About the other question, you find an MMX tutorial at: http://docs.tommesani.com/
Afternoon, WarlockD.
The appropriate use of asm in any application hasn't changed. It should only be used in bottlenecks....but only after the bottlenecking algorythm has been redesigned well.
Most speed issues in games are more to do with design errors, than with which language is used. In many cases, using C is just as efficient (if not more so) than delving into assembly. It's the old adage: A good assembly programmer will always out-perform a good C programmer. However a good C programmer will always out-perform a bad assembly programmer.
Cheers,
Scronty
What I am asking is not WHAT I should use, but when is using ASM approprate in games with the high efficencey compilers are, now adays.
The appropriate use of asm in any application hasn't changed. It should only be used in bottlenecks....but only after the bottlenecking algorythm has been redesigned well.
Most speed issues in games are more to do with design errors, than with which language is used. In many cases, using C is just as efficient (if not more so) than delving into assembly. It's the old adage: A good assembly programmer will always out-perform a good C programmer. However a good C programmer will always out-perform a bad assembly programmer.
Cheers,
Scronty
Funny you should ask. I'm switching back and forth between C++ and asm right now. Depends on my mood.
A little history...
Many moons ago I was a hardware designer so asm was my only tool. Later, my boss insisted that we code our latest product in C. While learning C we found ourselves having to switch to asm because we couldn't get something to work right. This was mostly an a/d d/a medical system. I found that once I got comfortable coding in C I would plow right along until I hit a snag. Then I'd switch to asm just to get the damn thing to do what I wanted to do and stayed in asm until the boss complained.
I find myself switching again. I started coding a DirectX project in asm cause I was fighting with my compiler way too much. Then I started getting nervous and thought it might be worth some headaches to let C++ do some thinking for me. But now I find myself constantly checking the assembly output to see if it's doing what I want it to do.
I agree that programming in asm with Windows is a lot like C and I actually feel more comfortable in asm because I know it's doing what I want it to do. Of course I look at the program's output to see if the VALUE's are what they should be, but I get nervous that it's not getting there the correct way. When I get into a difficult part of the code in asm, I feel I should be using C++ so it can solve my problems for me. (Do you hear that?!)
Another thought is I always have in the back of my mind the many problems I had coding in C++ and Windows trying to match the correct parameter or variable name with Windows' .h file. I would know it's just a DWORD in asm but if you don't have the right name, the compiler will fart and look at you cross-eyed.
(I'm rambling now, I know). Many times I WANT to program in asm because it's comfortable but I feel I SHOULD program in C++ because you're supposed to. And "supposed to's" are poison to my blood and mind.
A little history...
Many moons ago I was a hardware designer so asm was my only tool. Later, my boss insisted that we code our latest product in C. While learning C we found ourselves having to switch to asm because we couldn't get something to work right. This was mostly an a/d d/a medical system. I found that once I got comfortable coding in C I would plow right along until I hit a snag. Then I'd switch to asm just to get the damn thing to do what I wanted to do and stayed in asm until the boss complained.
I find myself switching again. I started coding a DirectX project in asm cause I was fighting with my compiler way too much. Then I started getting nervous and thought it might be worth some headaches to let C++ do some thinking for me. But now I find myself constantly checking the assembly output to see if it's doing what I want it to do.
I agree that programming in asm with Windows is a lot like C and I actually feel more comfortable in asm because I know it's doing what I want it to do. Of course I look at the program's output to see if the VALUE's are what they should be, but I get nervous that it's not getting there the correct way. When I get into a difficult part of the code in asm, I feel I should be using C++ so it can solve my problems for me. (Do you hear that?!)
Another thought is I always have in the back of my mind the many problems I had coding in C++ and Windows trying to match the correct parameter or variable name with Windows' .h file. I would know it's just a DWORD in asm but if you don't have the right name, the compiler will fart and look at you cross-eyed.
(I'm rambling now, I know). Many times I WANT to program in asm because it's comfortable but I feel I SHOULD program in C++ because you're supposed to. And "supposed to's" are poison to my blood and mind.
ASM is a lot more work IMHO - you have to think about the program in levels of complexity, whereas in a HLL much of lower levels of complexity can be hidden and you choose to access low levels (inline ASM). ASM by itself is often like being adrift in the open sea. HLLs are like a barge in a lock. :)
For me, it doesnt matter, I'm not a hardcore optimizer, the reason I use Assembly is because of its simplicity, abstraction in my eyes is a b****. I can still code in C, but I use Assembly mostly. I use the same methods in C for Assembly. For example in loops/functions that are called often I must optimize but the others that arent called so often I just make sure they work and won't even go through an optimizing pass with it. I mean no matter what language you use, if you spend your time optimizing stuff that isnt used by the main program often you'll waste your time. No point in optimized Loader code.
I totally agree with "Dr Howard Dr Fine Dr Howard" (what a nick!). I am not an expert in asm, but in C and C++ I didn't know anything about what the compiler makes with my proggie, and asm helped me understand everything I needed to. And I hate those thousands of data types, that are in fact all DWORDs, and mostly I hate pressing SHIFT, especially for round brackets () & {}, and as you know C/C++ programming needs A LOT of (). And the speed... I was very surprised to make my computer make hundreds of millions of calculations per second, compared to the only several million calculations of the same code at C (using LCC ). Luckily I did only a couple of months programming in C and C++. When I got into asm, I tried all C and C++ proggies I had written, and screamed, seeing the output. Well, not every app was slow, but all apps could be boosted several times. The peak of slowness was a C++ proggie, a poliphonic synth, which at poly 10 takes all the cpu. Now I've written a version of it into asm, that takes nearly ... 50 times less cpu! And errors in asm can be detected easier, with the VKDEBUG window
A thing I hate about C++ is classes, which are not being exported to plug-in DLLs. class->func() should be optimized if not exported, but I haven't seen anywhere a sample. (btw, I suppose the "inline" statement might fix this, I haven't researched, and I won't either)
ASM == perfect
A thing I hate about C++ is classes, which are not being exported to plug-in DLLs. class->func() should be optimized if not exported, but I haven't seen anywhere a sample. (btw, I suppose the "inline" statement might fix this, I haven't researched, and I won't either)
ASM == perfect