Hi there!
After days of searching for good book about MASM & Assembler i finally give up. Can you share with me any good books / articles titles? At this day im C++/C# programmer who want to go in computer graphics direction and I think that Assembler could be great addition. Or maybe MASM isn't such great choice for Windows graphic programming?
No, the days when you wanted/needed to use MASM for Windows graphics programming are long, long, long gone. Don't even bother.
I don't want to program graphics in assembly (like, say, write whole program in it), rather use it for parts of code where i will need maximum performance. Soooo - still bad idea?
Modern compilers are much better at optimizing code than they used to be. Without a deep understanding of processor architecture, you're much better off writing clean C++ code, and leaving the assembly-level optimization to the compiler.
Modern compilers are much better at optimizing code than they used to be. Without a deep understanding of processor architecture, you're much better off writing clean C++ code, and leaving the assembly-level optimization to the compiler.
Yeah, and not only clean but also "sane" and with performance in mind. I remember seeing some code recently which copied a buffer into an STL list of bytes. It looked clean but it was simply *wrong* (or stupid?).
Anyway if you want to start learning assembly one way to do it is to start writing some small routines in C and disassembling them (with debuggers like gdb you are even able to have a view of disassembly with interleaved corresponding C code (I mean /m switch here)).
But with learning assembler you need to know a lot of things around like ABIs of your target platform, details on ISA, details on syntax of your assembler of choice. It would be also nice to have some idea about linking and C++ ABI if you want to use assembly with C++ code. And if you want to write in asm to get better performance you'll want to know timings of exact mnemonics on your target processor and details on how your target CPU works. And even if you make your code super-optimal for certain core it probably won't have the same performance on different one (e.g. intel vs amd, or even various intel chips).
It's all very interesting knowledge, but it's really lots of it and I seriously doubt you could write anything more optimal in terms of performance than what modern compilers can generate for you. + if you want it for making games then probably you mean intel ISA, and this brings even more details and problems.
I don't want to discourage you, I think it's still worth knowing, but not exactly for making computer games.
Cheers,
hs.
Agreed with what everyone else has said so far -- The first thing you want to concentrate on is writing clean, straight-forward, algorithmically-sound code in a high-level language like C++. In addition to being algorithmically-sound, you also want to be aware of how your data-structures occupy memory, and how your algorithms traverse that memory-space when doing work. Because processors themselves are so fast these days, they spend a great deal of time simply waiting for the memory system to catch up -- therefore, if you optimize your memory use and memory access patterns, you optimize your application.
After you have chosen a good algorithm and considered memory access patterns, *then* you may want to take further steps if the performance of your straight-forward code is not up to snuff. The first step here would be to look at things you can do sticking strictly to the core high-level language: making sure you are const-correct (which you should be using anyhow), applying 'restrict' to appropriate pointers, using canonical looping patterns, etc. so that you enable the optimizer to do the best job it can. If performance is still insufficient, profile and/or analyze the generated assembly and consider massaging the high-level language code where the optimizer has done a poor job (perhaps it isn't unrolling a loop that it could, or isn't pre-fetching the next operand). After that, consider re-writing the code using assembler intrinsic, and only then if performance isn't good enough would you want to consider assembly. In most cases, if intrinsics haven't gotten you nearly there already, going down to assembly isn't going to get you the rest of the way.
All of this effort should be guided by profiling -- you should never try to guess where your hot-spots are, much less what the precise root cause of them is.
Also, cast off any notion you might have about the "hardcore game programmers of yesteryear" that lived and breathed assembly, spending weeks and months to eek out 5% performance improvement. No one has time for that anymore, and even big studios with that kind of expertise available rarely go through the trouble.
That said, being able to read and think in assembly, combined with being aware of computer and CPU architecture, is a good skill to have. The Kip Ervine book is excellent, as are Randall Hyde's Write Great Code vol. 1, and vol. 2, and his other book, The Art of Assembly Language. In particular, the Write Great Code books focus not so much on assembly, but on getting the most out of your high-level code using many of the techniques I've mentioned above.
Intel 80386 Reference Programmer's Manual is a good reference. (especially Part IV)
Here's a decent place to get started. I think it's GAS flavored rather than MASM, but they're similar enough that you shouldn't have any trouble.
Once you have enough of an understanding to recognize what's happening when you open the disassembler view in VS debugger, definitely use that as a learning aide. Write simple programs and watch how the compiler implements them. When you compile for debug (with optimization disabled) you should see easy-to-understand assembly. If you enable optimization you'll often see something very different.
It's not bad to learn assembly. In fact, it give you a lot of insight into how computers work, and that may influence the way you program in general. It's also very fun, for a certain type of people. Long story short, the benefits you get from learning assembly won't come so much from writing assembly, but more from understanding how computers work in general. Modern compilers are ridiculously smart, and they do the 'right thing', even in some really obscure situations. Moreover, optimization usually comes from changing the structure of a program rather than from changing the speed with which it executes some specific routine.
Just be aware of that and you should be fine.
Although everyone is correct about C++ compilers in general being excellent that shouldn't stop you from learning assembly. It is really fun little project and will teach you things that high level languages like C and C++ simply don't. Personally I'd recommend you learn assembly on an easier instruction set such as ARM rather than on AMD64 or i386.
Although everyone is correct about C++ compilers in general being excellent that shouldn't stop you from learning assembly. It is really fun little project and will teach you things that high level languages like C and C++ simply don't. Personally I'd recommend you learn assembly on an easier instruction set such as ARM rather than on AMD64 or i386.
The original i386 isn't that bad, it is pretty straightforward as the 386 had no cache, no out of order execution and fairly straight instruction timings, its only with the Pentium that things started to get out of hand. (the modern architectures are a mess, there are even differences in instruction latencies between the various core i7 models(so code that is optimal for a ivy-bridge might not be optimal for a nehalem)
