----------------- Assembly Theory ----------------- Prologue: This is an essay I threw together for an English outcome when I was struggling for a topic. It is "dumbed-down" for an English-teacher audience, but it might be useful for new Assembly programmers. ----------------- Programming is perhaps the most enthralling of all modern hobbies and the most interesting and rewarding of all cutting-edge careers. It is intellectually challenging, requiring complex problem solving, decision-making, foresight and strategy, on the culmination of which is a clearly definable outcome. A program, that began as nothing, is now a great source of self-pride and achievement. Combined with some graphical design, it can even be a work of art. For the sake of the remainder of this article, it is assumed that you have delved, somewhat, into this digital world with what is known as a "high-level" language. Possibly you have had experience with BASIC (Beginners All-purpose Symbolic Instruction Code), FORTRAN, COBOL or any one of that family: Programs that use predefined English (language)-based words and phrases to make other programs. However, as you have begun to write more and more complex programs, you may have noticed that your "High-level" language is not making programs that run quite as fast as you like. This is where Assembly enters the stage. [Pauses for audience applause.] Assembly is what is known as - you guessed it - a "Low-level" language. It is now time to introduce the microprocessor and briefly state that: the microprocessor is down the bottom and "Low-level" languages are closer to it than "High-level" languages. The microprocessor is, if you like, the brains of a computer. It manipulates data based on two types of operations termed: arithmetic and logical. Arithmetic operations are those that add, subtract, multiply and divide numbers. Logical operators compare such numerical data, allowing for different courses of action to be taken. In other words, an "If... Then" question. For example: if something equals one, then add two to it, if it doesn't, then subtract three from it. And, thus, the two types of operations are combined. Assembly programming involves directly telling the microprocessor which one of the above operations to do and when. But, make no mistake: this is not as easy as it sounds. There are lots of strict, un-bendable rules that you must follow in order to do this, and there are many limitations. For starters, it is only possible, in the immediate sense, to use whole numbers between zero and 255 or 65535. The microprocessor, also, can only multiply, divide, add or subtract one number with one other number at any one time. It is also easily possible to crash a computer by telling the microprocessor to do something it doesn't like - and it doesn't like a lot of things. This is just to name a few. For these reasons, almost as soon as Personal Computers (PCs) were invented, so where "High-level" languages. The advantage of which was the ease at which programs could be written, the sacrifice of which was speed. The problem within which this lies is ignorance. Programmers using a "High-level" language do not know what the microprocessor is doing, and the "High-level" language does not know what the programmer wants to do. To explain this lets pretend that the programmer is making a fruit-salad. Let us also pretend that the "High-level" language is their helper. However, this helper can only perform one task at a time and has no idea of the overall aim. So, the programmer wants an apple. Their helper leaves the kitchen, walks out the front door, gets in the car, drives to the super-market, buys an apple, and returns home. The programmer then wants a banana. So the helper leaves the kitchen, goes to the supermarket, gets a banana and returns home again. When the programmer wants a watermelon, not only is the task repeated, but the helper buys an entire watermelon, even though a small amount is required. Had the helper been an Assembly language, it, in a sense, would have been able to make a shopping-list, one trip and only buy the minimal amounts. Such practice, commonly called "optimisation", puts less strain on the microprocessor, speeding up the time taken to perform the overall task: Making a fruit salad. It can also be seen from this, however, why a "High-level" language is easier to use. All the programmer needs to do is say "apple" to their helper, and it will be delivered. When writing everyday data-management programs, such as class name rôles, timetable makers or financial management tools, a "High-level" language will suit your needs in most ways. However, when it comes to graphics and game development, it is worth taking the time and effort to learn and use Assembly. Why? Think of a computer screen made up of lots of tiny dots (pixels), each a particular colour. If this screen is, say, 800 pixels high and 1024 wide, this is 819200 pixels! If you are making a game, then this is a lot of dots to calculate the colour of in a short time. You will probably find that a "High-level" language will not stand up the challenge. The biggest reason for learning assembly, however, is that it is even more interesting, challenging and fun than anything you have ever done before.