Sorry your browser is not supported!

When I was a kid, I tried my hand at TI-83 assembly programming - when I could barely handle TI-BASIC. All I did at that point was take code snippets people would give me telling me "This will work for you - just modify /a/ and /b/." for TI-BASIC.

Well, I managed to get a few images to show, but that was about it.

Nowadays, I look back on ASM coding for those machines, and realize how truly easy it is. The only downside is that there's very little in the way of good documentation, it seems.

Also I've done ASM programming on the x86 PC about 4-5 years later with more understanding at that point, mostly 16-bit programming, but I have done some 32-bit programming when I played around with making bootloaders.

How many of you have programmed in assembly and what's your take on it? I actually kind of enjoyed it.

I got into 6502 (more specifically 6510 for commodore 64) assembly on my 8-bit computers, mainly because it was nearly impossible to do any type of graphics game without it. It was a love hate thing for me. From what I remember of the assemblers I used back then... they were single pass and they required you to calculate the number of bytes per instruction to know what address to start the next instruction. They didn't have many features, and my computers didn't have enough memory to even leave comments in. It was a fight for every bit. Using memory maps to find places to store programs was also a concern. Especially given the face that 0 page memory, though extremely limited, was faster than other areas.

I had to work with 80x86 assembly as part of my core curriculum in college. While I enjoyed it, I must admit I wasn't great at it... relatively speaking. For example.

I have purchased copies of Michael Abrash's "Graphics Programming Black Book" (which he has made available free in digital form), "Zen of Assembly Language: Knowledge" (Which is where my forum name comes from), & "Zen of Graphics Programming : ...". I have read them cover to cover multiple times. Not that I absorbed everything. If you want to read something, that as a programmer, would absolutely blow your mind... then I suggest reading the 'Black Book'. Even if a lot of it is obsolete today, it's a life-changing experience to get inside the mind of one of the best game graphics programmers ever.

I can truly admire the brilliance of people like Michael Abrash and John Carmack. It makes you appreciate assembly language. But it also made me realize that I didn't have it in me to be "THAT" awesome at it. Especially now with API's like directX and the quality of say C compilers these days. I highly doubt that I could write better code than the compilers, and given that there isn't much need to talk with the hardware directly (given DirectX, or Opengl), I don't have much drive these days to get better at it.

TANSTATFC - "There Ain't No Such Thing As The Fastest Code" =)

Graphics Programming Black Book (FREE)
http://drdobbs.com/high-performance-computing/184404919

For those who don't know who Michael Abrash is... Here are some of his credits. I'll have to add some more recent credits (IIRC he is now with Valve). I know he did some work with Graphics Card manufacuters as well.

Michael Abrash is considered one of the greatest programmers of today. With a career that spans from 1982 to today, it's no wonder why he's so famous. His claims to fame include writing the Graphics Programming Black Book and assisting John Carmack in Quake and Doom. He was a former mentor of John Carmack, another game programming legend. In fact, Carmack considers Abrash to rival his own programming talent. Michael Abrash also helped to develop the Microsoft XBox.

Here is a list of books for which Michael Abrash has partial credit:
1984 - IBM PCJR Graphics
1985 - IBM PCJR User's Guide

Here is a list of books written by Michael Abrash:
1989 - Power Graphics Programming
1990 - Zen of Assembly Language
1994 - Zen of Graphics Programming
1994 - Zen of Code Optimization
1996 - Zen of Graphics Programming, Second Edition
1997 - Graphics Programming Black Book

Finally, a list of games for which Michael Abrash has partial (and full) credit:
1982 - Space Strike
1982 - Snack Attack II
1982 - Cosmic Crusader
1983 - Big Top
1993 - Doom
1995 - The Ultimate Doom
1996 - Quake
1998 - Half-Life
1999 - Half-Life (Game of the Year Edition)
2000 - Motocross Madness 2
2000 - Microsoft Flight Simulator 2000
2000 - Half-Life: Platinum Collection
2001 - Serious Sam: The First Encounter

February 1, 2009 10:00 PM PST

Michael Abrash is a programmer at RAD Game Tools, working with Intel on the Larrabee project. He is co-author of the Pixomatic software renderer. He worked on Quake at id Software and on Windows NT and Xbox at Microsoft.

2011 Abrash signs on with Valve Software
http://www.develop-online.net/news/37665/Valve-hires-world-class-development-trio

I tried assembly very recently, and got a little way passed the usual hello world, and Russian roulette code examples. While I'm sure it has massive speed advantages, from a development point of view I'd rather stick with C++ and BASIC Style languages. BASIC languages are ideal for prototyping idea's I find, and App Game Kit's multi-platform support from a single source is massively beneficial.

I like assembly as a concept, but for real world development, unless I was planning to write my own compiler, I don't think it provides any realistic benefits in a real world situation. At least not in the world of games, and Operating System applications.

After many years of programming Z80, 6502, 6809 and then onto the 680x0 I've always been a fan of assembly programming personally. And especially now after studying and re-learning it with the x86 onwards it's amazing how processors have progressed. A simple instruction on a Z80 for example would take 4 clock cycles where as with the new fam-dangled pipeline caches in these new processors you can if using optimised instructions run upto 6 instructions and only use 1 clock cycle. This is a great advantage for multi-core processing as using this advantage can give blitter like speeds.

Saying that though, as with most people, I write my stuff first and then look at optimising the critical parts with assembly, and for the most part there's is actually only a slight increase in speed. However working with image processing on ^2 boundaries you can reach blitter capabilities working within the pipeline cache sizes.

The speed differences only really come into affect when pasting images, memory copying, simple memory modifying, that sort of thing.

Cross-platform programming has no benefit of assembly unless the programmer puts in those chunks manually specific for various processor platforms (ie PC, MAC), but nowadays it seems even cross-platform programming cannot even take advantage of it as it has now moved to mobile devices.

Basically an assembler programmer would not dream of a function that calls a function that calls a function, like a lot of languages these days. Everything has to be on the fly processing. With the speed of processors now, assembly programming is slowly going out of fashion though...

Assembler is awesome. The level of control you get with it is unparalleled.
You can do some very intricate acrobatics not possible with even C++, like on the fly modification of program code. I once made a variable encrypter, which would add a section to a PE file, modify the entry point so it would start the execution there, encrypt the .code section, and save the decryption key. Every time it decrypted the code, it would generate a new key, so when the program ended execution, it would encrypt it again with the new key.
This sort of thing would be impossible to make with any other high level language.
Like you, I started with 16 bit assembler, using Pascal for non critical stuff, and assembler for everything graphics related. That book zenassem recommended (Zen of Assembler Language), and "Zen of Graphics Programming" by the same author, are truly the best of it's kind, and although "Zen of Graphics Programming" is quite advanced, even a beginner can learn something useful from it.

My assembly programming is mostly in the ARC ISA these days, since I'm working on a project which has hardware development (with an ARC core or few) and instruction set simulation development involved. I have to say ARC has a very nice assembly language, it's extremely easy to read (I spend more time reading instruction traces in the simulator than writing assembler).

I'm not such a fan of x86 assembler, but I deal with it from time to time (writing it inline for optimisation, or reading it in the generated code to see what the compiler is doing).

I've done some PIC programming in the past, but I seems to remember coming away with the feeling it wasn't a very orthogonal ISA.

One thing I don't like about PIC assembly is how you "equ" memory addresses. It's really weird.

Learning 8088 ASM in class this year. We haven't gotten very far yet, but it seems like there's a lot of stuff that goes on behind the scenes that is implied by certain commands that isn't very obvious (automatic incrementing of counters and stuff). Seems odd for such a low-level language. Maybe 8088 is different.

I started with the Z80 on the Speccy and the speed difference between assembler and Speccy basic got me interested. One of my favourite commands was DJNZ (decrement and jump if not zero).

Learning Macros in assembler is essential as it will save typing hundreds (even thousands) of lines of code.

Most assembler commands affect the flags in various ways, loading a register will set various flags and a compare or test isn't needed. To gain the extra speed it helps to understand all the flags, overflow, carry, etc.

Non-assembler programmers will easily say its not necessary but I think it is for gaining that extra bit of speed.

BMacZero: The auto increment style instructions are actually very popular even in RISC ISAs, because they can be used efficiently when pushing/popping to/from the stack, and when iterating through arrays. They are 1 instruction for 2 big reasons:
They efficiently use the pipeline, encoding use of the ALU and memory units in a single instruction (especially useful with in order processors for performance) so what would be 2 instructions otherwise, can complete in the time of 1 (if you extend this trend you get a VLIW architecture).
They only take one instruction in the program code, so provides better code density, which has many advantages of its own.

@BMacZero:
As you go along, you'll love the auto incrementing feature. You just have to remember which registers auto increment, and which doesn't.
This feature was actually very helpful on the early days when there were no GPU's, you just had to loop a "mov esi, edi", a single instruction, to fill a screen with pixels, and not worry about incrementing the source array index and destination address. Extremely fast.
Edit:
Just read what mmozct posted. I have to work on my "impulse posting" issues

@Dextro: I hadn't though about the rasterisation/blitting advantages, but they are essentially the same as the array iterating I mentioned, along with memcpy, and string manipulation functions.

Also, my handle has a zero '0' in it, not an 'o' it's a callsign (I was too unoriginal to come up with a good handle years ago and now it's stuck as my internet handle everywhere).

ARM has some "if then else" block instruction encodings, which are really pretty nasty to simulate efficiently, because the state can change while executing in the block, such that both cases execute (if is true, then block executes and changes the state making it false, and then the else block also executes!).

Zero overhead loops are another nice feature of ARC, the compiler should emit them on any for(i...) style loop on an ISA with ZOL features (beware the corner cases when simulating/building hardware for these though).

Something really cool I found today was http://mainisusuallyafunction.blogspot.com/2011/10/phosphene-fractal-video-feedback-as-pc.html

I think anyone reading this thread will find it interesting.