I''m in an assembly language course right now and I''m finding that I suck at it. I''m so used to C++ and being able to make clean, easy to read (and therefore easy to debug) code. When I program in ASM, it''s a friggin mess and very hard to follow. I just feel like there have to be some kind of methods for programming well that I am missing. Does anyone know a good ASM site where I can find explanations/tutorials on how to program clean code in ASM? I''m programming on Motorola''s 68HC12 processor. Our IDE SUCKS. It''s a DOS based with no mouse support. It''s at such a low resolution that I can fit maybe 25 lines (tops) on the screen at a time. Compilation takes forever , so it is inefficient to check every 3 to 4 lines to see if you have any bugs. This is driving me nuts. Does anyone know of an emulator for the HC12, or some kind of IDE that I can load on my own computer?

Try this
http://e-www.motorola.com/collateral/MCUEZIDE.html

quote:
I just feel like there have to be some kind of methods for programming well that I am missing. Does anyone know a good ASM site where I can find explanations/tutorials on how to program clean code in ASM?

I haven''t seen any collections of tips on how to write good assembly language but it is something you pick up after a while.

Crusty old assembly code of mine that I dig up on my hard is most hard to read when dealing with hardware (through ports on the X86.) The actual assembly code is easy to follow because assembly is so very simple.

Some tips I can think of off the top of my head:

1. Have a good heading comment for all of your procedures describing registers in, registers out, and any side effects (registers or memory clobbered) as well as a description of what the procedure does along with a brief description of how it does it (standard stuff, really -- I do this in my high-level code as well.)

2. Use some consistent method of aligning your code. You might want to have all instruction mnemonics in one column and all operands in another. You may also wish to actually indent things as you would in C relative to labels (helps a lot with nested loops.)

3. Write good comments. Comment any mathematical/logical tricks which aren''t obviously apparent (XORing 2 registers with themselves or with 1 are obvious, some weird combination of NOTs, ANDs, and ORs probably won''t be.) Write block comments in front of sequences of instruction within a procedure which are supposed to do some part of the procedure''s algorithm. Describe what the handful of instructions does and how they do it.

For particularly nasty pieces of code where registers are being moved around a lot and pushed/popped from memory, you may also want to describe regs in, regs out, regs clobbered, or write out diagrams each step of the way describing what is in which register at a given point.

4. Adhere to the rules of good structured/procedural programming. Things like OOP are obviously not practical at the assembly level (particularly when working on small projects or code that interfaces with an HLL.) At the assembly level, you''ll unfortunately be forced to think in a way that actually makes sense: procedural programming

Just because it''s assembly doesn''t mean you have to write spaghetti code or avoid modularity and reusability.

quote:
I''m programming on Motorola''s 68HC12 processor.

Isn''t this an old 8-bit MPU? Thank goodness for modern architectures

quote:
Our IDE SUCKS. It''s a DOS based with no mouse support. It''s at such a low resolution that I can fit maybe 25 lines (tops) on the screen at a time.

I still use MS-DOS Editor a lot. It also uses an 80x25 (or 80x50, if you really want to) display, which limits the number of lines to 22 because of the 3 lines taken by the GUI.

I love it. Easy on the eyes and it does what I need it to do.

Anyway, I don''t see much of a point for assembly IDEs (or IDEs in general, but I digress...)

quote:
Compilation takes forever , so it is inefficient to check every 3 to 4 lines to see if you have any bugs.

Assemblers should be extremely fast. They''re not real compilers, after all. They don''t do a fraction of the same amount of work and are far more simplistic.