Welcome to Kohlrak's programming tutorials. I'd give myself a good introduction, but by the time I'm done with this series, the introduction will have long lost it's relevance, because I will have acquired that much more knowledge. Most of what you will be learning I've already been there and done that. Some, however, will be new to me, but those are going to be the very late lessons. Anyway, I will state that this particular document is full of disorganized information. At the bottom will be 4 video tutorials to help you get started.

I want to start off by saying that programming is an art much like poetry, and just like poetry, you have a lot of fun playing with things in the end, but at the same time you have a lot of boring stuff in the beginning. And here in-lies the problem I have had with all my previous tutorials, and never had a solution for, until (hopefully) now. When you are learning how to write stories and poetry, you have to first learn the boring alphabet then boring writing then boring spelling then boring sentences then boring punctuation then boring grammar. To make matters worse, you have to learn to run before you walk: you have to write to memorize the alphabet, you have to use spelling that you don't understand to learn writing, and the list goes on. I want to save these things called "macros" for last, but unfortunately you will have to use them before you are ready to learn how to make them.

The main point in making my own operating system and making you go through all that trouble just to run a testing program was that I could severely limit the amount of this stuff that you have to learn. Macros act like regular commands, but actually aren't regular and thus only apply to certain systems. This makes it hard for the learner, because then you have to try to figure out what's real and what's not. Instead, I provide only a few macros that you really don't even have to understand to use them. Due to their simple nature, they will be covered when the time comes, however you will probably continue to use them, anyway, due to what they save you from having to type (lots of text). Google will be your friend in this, as much of what you are given you won't understand right away. For example, I managed to google this document, that you need to read, on binary and hex-decimal. You will need it, later.

As you might have guessed, this will probably be one of the longest documents in this series. I want to try to cover everything necessary to get you to your first program. First off, you need to know what exactly you're doing. You are to type letters using a certain "syntax" which is understood by a program. This program takes your work (we call this "source code") and reads it multiple times, slowly replacing what it can until it either ends up making a "binary file" (your program) or finds something it cannot figure out ("syntax error"). It's important to understand that there are multiple layers to the process: meaning that you can make the assembler do some of the work for you, and also do some of the work for the program. The resulting binary file will no longer have the assembler to rely on, so what the assembler doesn't do for it, it will have to do for itself. The more it has to do, the slower it will be. Fortunately, it is easy to predict what the assembler will do for it, and what it will have to do for itself.

Firstly, the assembler must keep track of "labels" which are words that represent things that the assembler must understand. There are many, many types of labels, each with a specific use. Most of the labels I will cover in the macro section, however you will need to understand exactly what a label is before you can continue. One example would be "a = 4" where the assembler replaces every "a" that has a space on both sides with the number "4." "a" never actually ends up in your binary file, but instead is used by your assembler only. You can also do "b = a + a" which then "b" gets replaced with "a + a" which then gets replaced with "4 + 4" which your assembler is then smart enough to turn into "8" for you and your program. This is very useful, since there are many numbers that represent certain things, but it's easier to remember what those things are than the numbers that represent them. So, say, if the left mouse button gets represented with the number "2882992" (yes, I hit random numbers on my keyboard) it's easier to remember something like "mouse_lbutton" or something like that.

The processor family we are to be working with is the x86. Your code is written from it's point of view: there's itself, RAM, and Input/Output. All programs are stored in RAM, and slowly each command gets read by the processor (the CPU [the big tower is not your CPU, the CPU is the small chip that does most of the work]). I/O is anything that isn't itself or RAM. The CPU doesn't understand what exactly it's talking to, it just follows orders, so unfortunately there isn't a "get mouse location" command or something simple like that. However, that's what "functions" are for. Functions are commands that can be "called" by your program to do work for you so you don't have to do it yourself. Functions, however, must be present. The point of my kernel was to provide these functions to you so you could limit how much you had to do just to make your first few computer programs: that way you do not end up overwhelmed.

Your first program's job is to keep the computer from crashing. This is a simple task, actually, but doesn't use any x86 assembly commands. In the end, it uses only macro, which represent x86 assembly commands. The first macro is "begin." "begin" basically gives the kernel all the information it needs to put your program into ram and to execute it. "end" is used to help give the begin macro information. Anything that you put after the "end" macro will be assembled by the assembler, but it will no be automatically loaded into RAM. "terminate" makes the execution of your program stop. Anything you put after it will still be loaded. The reason for this surely isn't apparent to you right now, but it will be very quickly.

To prevent confusion, hex either begins with "0x" or ends with "h," but never both (decimal can optionally be suffixed with the letter "d"). So 0xa=10d. Binary is base 2, so it goes 0, 1, 10, 11, 100, 101, 110, 111, 1000. It is often suffixed with "b" to prevent confusion (these suffices are *NOT* optional in programming).

Both hex and binary are often "aligned" when writing. Meaning, since they're used in computers, there is often a limit of digits that can be used in a certain piece of code, and since we know that limit, we often put 0s to the left to make things easier to read. It's entirely optional, but it's very similar to the practice of doing it with decimal, like how you see on some machines where you see "01" instead of simply "1." In computers, a byte is 8 bits (8 binary digits). Therefore, if you had a byte representing the value 2, you would write "00000010b." The problem with binary is thatwhile each bit can represent a long list of answers to yes-no questions, after 8 bits, it often becomes very difficult to keep track of your location. This is why we use hex. 1 hex digit can represent 1 nibble (half a byte, and no, I'm not kidding). Conversion between binary and hex is as simple as memorizing 16 binary values and 16 corresponding digits, then going 4 bits at a time.









Anyway, off to your first program. "Lesson 1" in the "x86 instructions" section.

Oh, but one last thing. Things will seem useless and worthless at first. The instructions tutorial is to give you the primery that you need to do the rest, however when writing, I had alot of "chicken or the egg" problems to deal with. So bear with me and understand that the instruction lessons seem useless and boring, but they prepare you for the future lessons.

Get your own web kitty here!
┬ęCopyright 2010, 2011, 2012, 2013, 2014, 2017. All rights reserved.