Kris1978 wrote:
Phew!
I was scared for a moment. Now I understand. Okay, I think an afternoon reading of the manual of the x assembler will be okay....
Yes, it's just some syntax details for the assembler, not any differences in the language itself. It would be nice if all assemblers were completely compatible; but differences may arise from various assembler writers' efforts to help the user make his code clear or to be able to adapt to various users' preferences, versus possible challenges like making the assembler fit in the very limited memory space of a smaller system. (To clear up some possible confusion in that statement: The assembl
er is the tool that converts assembly-language source code to the machine language that the processor can understand. The language itself is "assembl
y language," not "assembl
er." You'll see a lot of word misuse though.)
scotws wrote:
A big project forces you to learn how to structure the code at a whole different level.
+1. The beginner tends to not want to be bothered with things he regards as superfluous and making the source code "pretty." But as you gain experience and your projects get bigger and bigger, you'll find that it's easy to lose control of them and reach a point where you feel totally lost in your effort to find and fix a bug, make a change, etc., and you'll feel like the only solution is to start over! To minimize that growing pain, try to get into good habits early on. Admittedly, you won't initially know what these good habits even
are; but do keep an open mind about the next strategies to learn.
Macros were mentioned earlier. I wouldn't spring them on the complete newbie, but I would encourage jumping in soon after the basics of assembly-language programming have become familiar. Ed linked above to my article on macros. It starts out with what a macro
is, but the thrust of the article is to use them for the less-obvious things you can do with them, particularly program-flow-control structures.
A video I saw of a lecture on programming had a couple of great quotes:
- Programs must not be regarded as code for computers, but as literature for humans.
- Reducing size and complexity is the triumph.