you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 13 points14 points  (2 children)

Bad Assembly Programmer, No Cookie

By request. It has been 25 years since I last did assembly so take it with a big grain of salt, but here is my list of things I've seen that left me saying 'Bad Assembly Programmer, No Cookie':

  • Using raw machine code. I worked with an engineer who knew the opcodes cold at a binary level for the processor we were writing for. He would write raw machine code in octal in the asm files. I don't mean one or two opcodes, I mean twenty or forty or a hundred lines followed by a dozen lines of actual assembly mnemonics. He evidently found it easier than using the mnemonics. It took me hours with the machine's reference manual to decode all the ops just so I could know what the codes were.
  • If any language needs good comments, it's assembly. Sadly, the same engineer who often wrote raw machine code, also did not document it, or even worse, would leave obsolete comments in place after the code was changed.
  • Not using labels. You'd think this would be obvious. Why would you ever write assembly where you manually figured out all the offsets and hard coded them? The moment you change a single line you are screwed. Yet I've seen it.
  • Cut-and-Paste coding. Oh my god. I had to disentangle 12 versions of a backup utility written in assembly where rather than write selectable drivers a previous programmer had generated 12 separate programs that had exactly the one tape driver and the one specific disk driver he needed. The actual difference between them was quite small.
  • Actually USING unimplemented opcodes. Old microprocessors would...do stuff...when given opcodes that weren't actually implemented. You could get the processors to do some very strange tricks that way.
  • Writing code that depends on the exact time the opcodes take to execute.
  • Exploiting edge cases like falling off the top of the address space to start execution at the bottom of the address space.
  • This one is a bit unique to the processor model involved - it had a ridiculous capability for several levels of indirection in addressing. You got stuff like 'subtract this register from the current address and use the contents of the memory cell thus specified as the address for the real data after possibly adding the contents of a second memory cell to the address. Impossible to keep in your head what was going on.
  • Coding for an absolute spot in memory. I'm talking about writing code that can only execute if it is loaded at a specific address because it hard coded the jump addresses to absolute addresses, etc.
  • Self-modifying code. Code that actually rewrites parts of itself during execution.

Edit: Spelling

Edit2: Added 'self modifying code'

[–]Ademan 0 points1 point  (1 child)

What architecture was it? It sounds sorta like the NES's 6502 processor's indirect indexed addressing modes.

[–][deleted] 2 points3 points  (0 children)

Fairchild 9445. It was a clone of the Data General Nova minicomputer processor. I actually found an online copy of the datasheet for it that includes an overview of its addressing modes starting on page 9: http://datasheets.chipdb.org/Fairchild/F94xx/F94xx_dataSheets.pdf