How to think like an assembly programmer

[Dr1v3n]

After reading some responses here and elsewhere from more experienced assembly language developers, I realized that my entire thought patterns right now are limited to higher level language-based thinking... Especially C, as that is the language I am most fluent in.

There have also been times where I've seen an asm programmer take a program that I've (or someone else) has written, that seemed rather boring or even compiler-output-like, and turn it into a program that a real, seasoned assembly programmer would write... Something that would never come from a compiler... something... more idiomatic if you will.

I want to get to that level, but I have no idea how to get there. A good example is another member here in another thread told me "remember, youre not limited to single return values like C." I never explictly thought I was, but I also never really thought that I wasn't. I need a way to open up and expand my horizons, almost as if I had never programmed before and assembly was my first and only language...

Do you have any recommendations?

[debs3759]

I find it is easiest to break a complex sequence of tasks down to a long sequence of more basic instructions, much like how I do maths in my head. I'm not skilled enough to explain it properly, but basically it's easiest to think in terms of writing pseudo code, then thinking how you can break each section down into simpler instructions, until you have it simplified enough for your pseudo code to translate easily into assembly code. I think in terms of math when I'm coding, and I heavily comment throughout my code so that it is easier to follow 10 years later if I need to, and it helps when I come across bugs in my code.

[fredericopissarra]

Each one of us learn something in different ways. For me, in 90's, I've got a nice material to study in the old Dr. Dobb's Magazine (Michael Abrash and his Graphics Programming column and later on Zen of Graphics Programming and Zen of Code Optimization books -- I was inspired by those), but stated with old 8 bit processors (Z-80 and MOSTech 6502 [Apple II]).

I wrote some "books" on the subject [sorry... in portuguese], trying to teach assembly to the novice, again, inspired on Abrash way of writing... And, never trying to build an entire project in assembly. If you are familiar with C I can only offer an advice: Use assembly only if you are certain that your routine is way better that one implemented in C. This because C compilers are very good (but not perfect) in creating optimized code. Most of the time, way better than you'll do.

My tendency, nowadays, is to create a routine in C; take a look at the assembly listing created by the compiler; and decide if I could do better (again, most of the time, I think I can't). Alas, this technique is good to learn how to create good assembly code -- and to refine your own C code.

This warning to almost never do assembly and trust the compiler has a purpose: Assembly code is often non protable. This is true, even, among the various "families" os architectures available for the SAME "kind" of processors: Exemple... if you are creating code for an old 486 and use R?? registers or SSE, it will not work!

My comment on "thinking in terms of math", by debs3759, is that technique is great, for every kind of programming (assembly or not), but I prefer to fill my code with meaningful comments, instead (lern this with Abrash)... The thing is YOUR knowledge of math and programming will improve, maybe a lot, in 10 years. Taking a look at mathematical driven style in the future, with new knowledge and new way of doing things, can make your own code unreadable to yourself. In that sense, I think writing a program is like writing a book or trying to teach someone (yourself included) what you did there.

[]s
Fred