___ ___ / \..__ __../ \ << CHAPTER 8: STRUCTURISING >> \___/ \___/ When making bigger and bigger demo's and games it, structurising is an important issue. Contrary to what people say, even the most standard assembler offers quite alot of functions for doing this: EQUates: A good first step in making your code more flexible is using equates. One is defined by writing down this for instance: label: EQU 1 label2: EQU 10 Now if you use label in your code: move.w #label,d0 This moves whatever value you coupled to "label" into d0. The assembler sees the label and replaces it with the value. move.w #label*label2,d0 This moves label multiplied by label into d0. The assembler has no problems with statements like these. You can also add, subtract, and, or, divide labels with eachother. Equates are very handy for bigger sourcecodes, where a certain value is used very often. Equates make code more adaptable and often more readable. A good example is for instance the size of an effectwindow or the screendimensions. If you change either, you have a lot of code rewrite. But simply using EQU's solves the whole thing quite easily. Simply giving the labels' values will do the trick. RS: RS is basicly only used for defining datastructures. I've found them quite handy. They're defined like this: RSRESET * Indicate a new structure. headerid: RS.L 1 * 0 Headerid is one longword. headerxsize: RS.W 1 * 4 Xsize is one word. headerysize: RS.W 1 * 6 Ysize is one word. headersize: RS.B 0 * 8 total size of header They basicly define offsets for datafield in structures. Now you can use these offsets like this for instance: lea header_buffer,a0 * Get address of header. move.l #"HEAD",headerid(a0) * Move headerid in header. move.w #16,headerxsize(a0) * Move xsize in header. move.w #20,headerysize(a0) * Move ysize in header. lea headersize(a0),a0 * Get startaddress of data. Ofcourse this isn't very optimal code. The assembler just converts every label to an offset. So every move is an offset move. You might want to use "move ..,(a0)+" instead. That's ok, but you will lose out on easy adaptability of the header. So using RS is only really handy in situations where speed is not the leading issue and the code must be very readable. Directives: These are often used in combination with equates. Sometimes used to comment a block of code when an equate doesn't have the right value. use_testmode: EQU 1 IFNE use_testmode * These is additional code for the test mode. ; ; ELSE * These are instructions for when the testmode is disabled. ; ; ENDC "IFNE" is such a directive which includes a block depending on what value it tests. If the label isn't equal to zero (which it isn't), then the whole part will be included in the code. This is again done by the assembler. This is very nifty if your sourcecode can be assembled in different modes (for instance for black/white or color). Another little trick which might be very essential for optimisin is the "REPT" directive. REPT 4 move.l d0,(a0)+ ENDR This RePeaTs the instruction inbetween "REPT" and "ENDR" four times. This is done the hardcoded way. So it will actually look like this in the final executable: move.l d0,(a0)+ move.l d0,(a0)+ move.l d0,(a0)+ move.l d0,(a0)+ REPT can also be used in conjunction with a label: times_to_repeat: EQU 10 REPT times_to_repeat move.l d0,(a0)+ ENDR Especially for making innerloops a bit more optimised this can be very, very handy! Macro's: People either love 'em or hate 'em. (Hi evl! =)) Macro's pieces of code much like the subroutines, but they aren't called, but directly put in the executable by the assembler. Macro's can have parameters, so in fact you can use them to make assembler a bit more like a highlevel language. stupid_macro: MACRO move.l \1,d0 move.l \2,d1 ENDM * Actual program goes in here ; ; ; stupid_marco #1,#2 The problem is that the assembler replaces this with the code in the macro, but it's mostly hard to know what exactly stands in the macro's. Knowing your code is essential when debugging, so it can make your source harder to comprehend. Oh the other hand, it is the faster solution, because it doesn't suffer from a bsr/jsr, rts combination. So it is wise to use macro's only for very small pieces of code where this overhead seems like alot. Using macro's in combination with IFxx directives, you can construct highly optimised code for specific immediate-data parameters. Much like high-level compilers do. But please don't implement complete >100-line routines in a macro. It simply makes your code into a mess. Local labels: Perhaps one of the most used assembler options ever. And it's explained in here!! =) (Duuhhh....) When you've got hundreds of labels already in your sourcecode you might run out of new labels to use. To avoid your labels getting really big or strange, you could use local labels. The nifty extra of local labels is that you can only reference them in a local area in the code. That is: only inbetween two global labels. If you use Turbo Assembler, you can skip this. It hasn't got this feature. ******** :ExamplE: ******** bra .local1 * wrong!! global1: bra .local2 * correct .local1: bra .local2 * correct .local2: bra .local1 * correct global2: bra .local1 * wrong!! The local labels always have points "." in front of them. As you can see you can't reference local labels from behind another global label. Only between two global labels it's possible. Ofcourse you can declare local labels with the same names behind every new global label. Local labels are ideal for use in subroutines. If you force yourself to only use local labels within a subroutine you can check more easily if there are any references outside the subroutine perhaps causing bugs. Also it clears up the code because using 50 characters long names isn't anybody's idea of having fun. But beware that local labels don't show up in your debugger, so it might actually only be good to use if you've already proven your subroutines work bugfree. With debugging it's always better to use global labels, or at least until your sure that routine is bugfree. Register equates: I haven't seen this used much or used this myself very often. using register equates has the advantage of both keeping data in the internal registers (=faster) as well as having easy names for the register (=more readable). I only recommend to use this when the algorithm uses loads of registers, but not when the register gets a different function everytime. This because you can map multiple equated to one register, so sometimes it becomes unclear when a register is overwritten or not. A second disadvantage is the increased contrast between sourcecode and the final code. This can make debugging more painful. Still, a nice way to make code better readable.