assembler macros!
Posted: Wed Jun 16, 2010 1:32 am
At viewtopic.php?p=10745 , ElEctric_EyE wrote,
So here it is. Hopefully it will get a bunch of you into macros, even if you have been shying away from them because of that unsettling feeling of unfamiliarity that may have been shooing you away until now. When I was working on my first big (10,000+ lines) 6502 assembly-language project in the late 1980's, I showed it to a neighbor who was a programmer, and he introduced me to macros, showing me how I could make my software monstrosity a lot simpler and more readable by replacing various portions with macros. It turns out that he did me a huge favor.
Early on, I mentioned macros and gave a couple of examples in the "Tips" column, at viewtopic.php?p=2341#p2341 with a couple of cool (but small) examples.
I'm not familiar with the Kowalski assembler, but there seem to only be minor differences between assemblers, such that if you're familiar with one, you will probably be at least 90% literate in another. What I have for the C32 assembler from Universal Cross Assemblers for a BEQlong (since that one already came up) is:
then if you need a BEQ that's too long of a branch for the normal BEQ, use BEQlong:
using a label for an operand the same as you would use BEQ, and the macro assembles the BNE to get around the JMP instruction, like this:
The resulting assembled code is exactly the same as you would do by hand, but the source code is shorter and more readable, making it faster to write, easier to maintain, and less error-prone. These traits becomes more and more important as the macros get bigger and replace more spaghetti with a single, more-intuitive line in the source code.
So far, I have not tried to make it test to see if a regular conditional branch will reach and substitute the longer version if necessary-- not that it wouldn't have value, but in most cases it's easy to see if it will reach or not.
Macros leave you in complete control and there is normally absolutely zero penalty in runtime speed or memory. The point is to keep all the control and performance of assembly while removing the need to keep seeing all the internal details after you have set them up. Raising the level of the language by taking maximum advantage of macros is a good thing.
I'll resist the temptation to get too long and complex for a starting post, but I will say I'm jazzed to have started successfully using macros for program structures despite my assemblers' lack of assembler variable arrays and pointers into those arrays that I mentioned in the topic, "desirable assembler features" at viewtopic.php?t=1475 . That lack makes nesting them a little more of a pain, but I found it can be done. Edit, 7/28/12: I've done the nesting of structure macros now, and have an article and source code here.
Quote:
I am curious too... I never got around to making macros, or a data table... 2 votes! Maybe a different thread to keep this one pure?
So here it is. Hopefully it will get a bunch of you into macros, even if you have been shying away from them because of that unsettling feeling of unfamiliarity that may have been shooing you away until now. When I was working on my first big (10,000+ lines) 6502 assembly-language project in the late 1980's, I showed it to a neighbor who was a programmer, and he introduced me to macros, showing me how I could make my software monstrosity a lot simpler and more readable by replacing various portions with macros. It turns out that he did me a huge favor.
Early on, I mentioned macros and gave a couple of examples in the "Tips" column, at viewtopic.php?p=2341#p2341 with a couple of cool (but small) examples.
Quote:
I never learned to make macros on the Kowalski assembler, am using jump tables. Do you know how I can do macros on that for a long jump as you mentioned?
I'm not familiar with the Kowalski assembler, but there seem to only be minor differences between assemblers, such that if you're familiar with one, you will probably be at least 90% literate in another. What I have for the C32 assembler from Universal Cross Assemblers for a BEQlong (since that one already came up) is:
Code: Select all
BEQlong: MACRO LBL
BNE bel1
JMP LBL
bel1:
ENDM
;----------------------
then if you need a BEQ that's too long of a branch for the normal BEQ, use BEQlong:
Code: Select all
BEQlong FOOBAR ; If zero flag is set, jump to FOOBAR
using a label for an operand the same as you would use BEQ, and the macro assembles the BNE to get around the JMP instruction, like this:
Code: Select all
BNE bel1
JMP FOOBAR
bel1: <continue>
The resulting assembled code is exactly the same as you would do by hand, but the source code is shorter and more readable, making it faster to write, easier to maintain, and less error-prone. These traits becomes more and more important as the macros get bigger and replace more spaghetti with a single, more-intuitive line in the source code.
Quote:
I tried synthesizing the '816's branch long instruction in the Kowalski simulator thusly:
So far, I have not tried to make it test to see if a regular conditional branch will reach and substitute the longer version if necessary-- not that it wouldn't have value, but in most cases it's easy to see if it will reach or not.
Macros leave you in complete control and there is normally absolutely zero penalty in runtime speed or memory. The point is to keep all the control and performance of assembly while removing the need to keep seeing all the internal details after you have set them up. Raising the level of the language by taking maximum advantage of macros is a good thing.
I'll resist the temptation to get too long and complex for a starting post, but I will say I'm jazzed to have started successfully using macros for program structures despite my assemblers' lack of assembler variable arrays and pointers into those arrays that I mentioned in the topic, "desirable assembler features" at viewtopic.php?t=1475 . That lack makes nesting them a little more of a pain, but I found it can be done. Edit, 7/28/12: I've done the nesting of structure macros now, and have an article and source code here.
