Assembly isnt for one-liners anymore. As has already been mentioned, small asm functions that dont contain big loops will break your compilers optimization with no benefits to compensate.

My rule of thumb these days:

If I cannot link the assembly language routine from an external .obj, .lib, or .dll because the calling overhead will obviously outweight the benefits.. then its also not worthy of being inline assembler.

Assembly as a written language is dying, and inline assembly is being replaced with intrinsics. However, the usage of the two can be very similar.

There are a bunch of reasons why knowing an assembly language can be helpful:

- It teaches you how to think about code at the lowest practical level.
- It familiarizes you with concepts that are helpful for writing code for coprocessors (MMX, SSE, VMX, etc).
- It can be a great aid while debugging, especially in code that's not yours. ("What does blr mean?")

The third point is reason enough to learn it. However, it should be noted that a very high percentage of game industry coders will never have to write a line of assembly or touch an intrinsic. It's not an essential skill to succeed, but it's a very very large advantage to have if you're doing any sort of engine or graphics work.

Quote:Original post by VanillaSnake21
Thanks for the replies, I'm currently studying Java in my school, and I came upon a topic of stacks, before I used to think it's only used for memory management but a chapter in the book explains thats it's used in parsing and compiler development. For example to transform the infix to postfix. They gave some example code in Java, which came out to be a couple of hundred of lines long, which is pretty short for a high-language app. But then I realized how easily this could be done in assembly where I don't have to declare any classes, don't have to extend/implement anything, but simply say push this on stack, pop this off, move the ebx to a new position, rertieve the variable 8 bytes from ebx etc. Working with stacks seems almost native to assembly, is that something it could be used for? Thanks

That's a general stack data structure you're talking about, which is similar to and yet very different from the stack a processor uses while running. You don't usually use the processor's stack like you would a stack from your library for various reasons, though I suppose you could in some sort of convoluted way.

The stack is a very usefull data structure - thats why most processors have instructions specifically related to it, although almost never 'generalized' stack instructions.

You can often leverage stacks in game development where (for instance) a unit in an RTS might have a stack of commands it needs to accomplish. When a situation new and important happens, a response to it is pushed to the top of the units command stack by the A.I. so that later the unit can go back to what it was doing before.

Also, recursive functions are the lazy mans way of exploiting a stack. All recursive functions can be re-written as non-recursive in languages like C (some not needing a stack at all (called "tail recursive") and the rest can use an explicit local heap stack instead of the implicit processor call stack)

(note: its not always a good idea to avoid recursion - sometimes recursion is the subjectively best solution, as some recursive functions can be very clear and concise while the non-recursive counterparts arent necesarily so)

I never have the reason to use it. In the past year, I wrote some pieces of code in it, but every time I did, I realized there was a way to accomplish what I wrote with clean C++ code that yields basically the same ASM.

In my game, I only have one piece of assembly: __asm { int 3 }; - and it's located in the code for a break() command that can be called from my engine's built-in scripting language. The reason is to allow scripts executed from text files to break into the debugger, if I happen to need a breakpoint at a specific location in the script. What I usually do is just set a breakpoint in C++ code for an exported command that is going to be called from the script, as most of the time it would be called only once.

I'm going to say that most optimization should be accomplished by finding a better algorithm, or a better way of memory usage, or a better way of CPU usage, etc. Like, not allocating and releasing heap memory anywhere in the game loop on every iteration. For most people here, adding assembly to the mix is unlikely to accomplish anything. Unless you're doing some CPU-based image processing, like CPU based alpha blending or box blur, etc. Even for that, compilers today may be good enough at optimizing.