ORIGINALLY PUBLISHED IN LIMA NEWSLETTER JANUARY 1994 Assembler Executing #2 By Bob Carmany I reckon that it is time for another installment of my continuing adventures into A/L programming. Fortunately, most of this early material is fairly easy to understand. I think we examined the concept of registers and number conversion the last time so I'm going to look at how A/L statements are written. For the time being, the structure of the statements is all I can handle! Back to the book! It says that A/L statements can have up to four fields. Strangely enough, not all of them have to be present in a statement. In order, they are: Label, Op(eration) Code or Directive, Operand, and Comment. A label, the book says, is only required when you want to refer to a statement from another statement. I reckon it is sort of analogous to a CALL statement in XB -- a group of statements that make up a routine. At least that's the sense of it that I can discern! A label can be from 1 to 6 characters in length and the first character must be a letter (A to Z). A label is the first entry in a statement and each statement can have only one label. Logical enough! I think that I can understand this! The next part of an A/L statement is the Op-Code or directive. That tells the program what operation to perform on the third field. A simple Directive is MOV for move word. Any of the Op-Codes can be used but they must be spelled correctly (of course). Even my foggy mind can understand that! The third field is the Operand field -- the item to be manipulated by the Op-Code. There are some rules to follow with this lot as well. Whew! Talk about structured programming!! More than one operand must be seperated by a comma and spaces can only appear in an operand if they are between a pair of apostrophies (the A/L equivalent of parentheses). The last field is the Comment field. That is a freelance entry to explain what the statement was supposed to do --- and I emphasize SUPPOSED TO! It can extend to the end of the line. There are some general rules about the form of A/L source code. Each of the fields must be seperated from the other by at least one space. By convention, the fields are generally aligned when they are written. Oh yes, you can add general comments to your programs by using the asterisk "*" at the beginning of the line. It functions as a REM statement in XB. Although any text editor that outputs a D/V 80 file can be used to create source code, the best that I have found is F'WEB in the ASMode. All of the tabs have been fixed and the word-wrap has been turned off. In addition, the code is saved without the tab settings. I find it very easy to use when I'm about to "borrow" a bit of source code from an article somewhere. I haven't gotten far enough with this stuff to write my own code yet! Ok, let's see what a line of A/L source code might look like. This is for structure only so I have just picked some stuff out of the book: START MOV @@A,R0 Move A to Register 0 Here you have a Label, Op-Code, Operand, and Comment field. Now, it is time to take a look at a comparison between XB (which I understand) and A/L (which I don't). This example is a bit primitive but it is about all that I can muster right now. .NF .NA 100 DATA 1,7 Defines the two data items 1 and 7 110 READ X,Y Assigns the value 1 to X and 7 to Y 120 Z=X+Y Adds X and Y to get the value of Z The same program in A/L would look something like this: X DATA 1 Assigns the name X to the value 1 Y DATA 7 Assigns the name Y to the value of 7 Z BSS 2 Reserves 2 bytes of memory for the value Z MOV @X,R0 Moves X to work Register 0 MOV @Y,R1 Moves Y to work Register 1 A R0,R1 Adds Register 0 to Register 1 MOV R1,@Z Moves the sum to Register 1 replacing * the number there .FI .AD Bloody amazing! I learned how to add 1 and 7 in a program. Watch out Ron and Tony --- I'm on the way!! All you have to do from here is run the source code through the Assembler and you have a D/F object code file that you can LOAD AND RUN. Type in the input filename, an output filename and, after pressing the ASSEMBLER EXECUTING message appears. If you are lucky, you get a "0000 ERRORS" message when the Assembler is through. That would be a new experience for me! Even on stuff that I thought that I had typed in accurately from a printed copy I usually get "double digit" errors! I once typed in about 300 or so lines of source code directly (I thought) from a couple of issues of MICROpendium. It took me two days just to get the typos corrected in that mess!! After all of that, the silly program wouldn't even run. You can imagine how "happy" I was about that! Just wait until I start writing my own programs --- triple digit errors may not be out of the question! So far, I have to admit that A/L isn't nearly as difficult to understand as I thought that it would be. Of course, I haven't really started to do any substantive programming. I've managed to display a few bits of text on the screen and manipulate some numbers here and there but nothing that would qualify as a program. We'll have to see what the next month will bring! .PL 1