| |
Slammer
Registered: Feb 2004
Posts: 416 |
Kick Assembler Thread 2
The previous thread took a little long to load, so this is a new fresh one.. |
|
... 590 posts hidden. Click here to view all posts....
|
| |
soci
Registered: Sep 2003
Posts: 473 |
The current location symbol (*) is traditionally the location at the beginning of the line in many assemblers. That is before any bytes are output for opcodes and other stuff.
Unfortunately the handling of this is broken in this assembler (e.g. in v3.34), or at least it's hard to defend the way it works.
Simple stuff is fine, e.g.:
jmp *
results in (assembled to $2000):
00 20 4c 00 20
But let's see something else:
.word *, *
results in:
00 20 04 20 04 20
while the expected result is:
00 20 00 20 00 20
Yes, I also got this wrong too in some special cases in a different way just until 3 years ago.
For those hundreds of skip labels I use "anonymous" labels. Of course moderately, as copy-pasting skip label containing code in between is a sure way to get a long lasting debug session ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
well, 16 bit addition like that sort of works like a macro from my head, unless I get rusty like now. Editing is a bit easyer if you dont have to carry around the anonymous label definition ("+") too, just have the *+. :) |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Soci: Interesting details about the *. I didn't know of the 'start of line' convension for all directives and never used * together with '.word'. Could you give an example of where this is usefull with the word/byte directive? Which assemblers use it, and which don't? Since KickAssembler, like languages as C# and Java, are throwing lineshifts away in the preprocess, it will be a 'start of directive'-convention instead of 'start of line' (In kickass, you can write several commands on one line). Seams like a good convention. |
| |
soci
Registered: Sep 2003
Posts: 473 |
Start of directive/opcode is fine instead of line start, then it's consistent at least.
It works like this in acme, dasm, dreamass, tasm/tass, xa, nasm and maybe some others. ca65 has it wrong just as old 64tass versions, but at least both give correct results for code like below.
A useful example which stores 7 at len instead of 6.
txt: .text "abcdef"
len: .byte *-txt
|
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
Looks like Pantaloon's example solved the issue, thanks! - Ofcourse partially only, but it looks nicer now.
Oswald, the reason why i put it in .if is that when i give my code to another guy, he can just set DEBUG_MODE=0 flag in the beginning and compile to get SMC optimized final product.
So, if the very original code looked like this:
// (!) Remove the section below from final product!
SET_AVAR .byte 0
SET_XVAR .byte 0
SET_YVAR .byte 0
...
DEBUG_proggie:
lda SET_AVAR
ldx SET_XVAR
ldy SET_YVAR
...
SMC-converted program would be something like this: (faster+smaller):
// (!) Remove the section below from final product!
DEBUG_Proggie:
lda #0 .label SET_AVAR=*-1
ldx #0 .label SET_AVAR=*-1
ldy #0 .label SET_YVAR=*-1
...
Cute and nice. And I don't need to tell the another coder that he has to change all "sta SET_AVAR" etc into "sta SET_AVAR+1" (or +2 for words etc..) instead. That's the whole idea. But there's another thing left: The "Remove this section"... well, think there were 10 cases each put somewhat 10 pieces, that would result up to 100 code pieces to check through. There comes conditional assembly handy.
So instead of mentioning "Remove these sections.." i can just
.label DEBUG_MODE=1
...
.if (DEBUG_MODE==1) {
DEBUG_Proggie:
lda #0 .label SET_AVAR=*-1
ldx #0 .label SET_AVAR=*-1
ldy #0 .label SET_YVAR=*-1
}
But ofcourse not it doesn't work like this, so it turned out something like this:
.label DEBUG_MODE=1
...
DeBUG_Proggie:
.if (DEBUG_MODE==1) {
lda #0 }
.label SET_AVAR=*-1
.if (DEBUG_MODE==1) {
ldx #0 }
.label SET_XVAR=*-1
.if (DEBUG_MODE==1) {
ldy #0 }
.label SET_YVAR=*-1
And that was barely somehow readable...
Before someone nitpicking this was actually an oversimplified example. :) |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
About the * issue.. i was in thought that such errors shouldn't occur.. considered it a bug... so i did a choose to only use labels (tass), just to make sure avoiding erraneous pointers after compile.
One thing i never understood: Why anonymous labels and such, why not using plain labels anyway for branches and all? (Be it that C64 tass has limited space for labels, but for crossdev stuff like kickass we try to keep labels at minimum..?!) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
"lda #0 .label SET_AVAR=*-1"
now which one is more readable that or
"avar lda #0" ? :)
"And I don't need to tell the another coder that he has to change all "sta SET_AVAR" etc into "sta SET_AVAR+1" "
other coder should realize what you're doing after having seen how AVAR is defined and used. my method or yours, doesnt matter. if he is defined method agnostic :)
how about this:
"lda $1000 .label SET_AVARLO=*-1 .label SET_AVARHI=*-2"
still readable ?
the problem with your debug code is kickass, it shouldnt define the conditinal code sections as scopes automagically.
I dont like all that bracketing stuff either, in 64tass its just .if .fi the end.
* stuff, after the 12000th label you get tired of having to think of and type in another dummy one, which wasnt already used. bcc *+4 can be written without any thinking, duplicate checking. |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
The latter is more readable ofcourse. But its readability is just for me, the other coder doesn't need to edit it at all. Only compile in general. And all data variables that previously pointed to some .byte array now points to SMC operand and still no need to change any labels in his code to point to *+1 instead.. See what i mean. :)
I see your point, but is there any other means at all to nicely access the operand by label pointer instead of opcode? Atleast that i haven't seen such in any assembly specifications... you know better.
And the point of having conditional assembly and flags is to get rid of that code easily. A good example is SDI, it's almost a miracle that some conditional assembly works in c64 tasm! ;) |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
Well i use nowadays some prefix to labels and stuff, f.e. music routine calls could be just M_INIT, M_PLAY and M_PLAYMSPD. Can't mix. The * stuff was never self-explanative to me and easily messed up with some other similiar looking routine. For zeropage variables i always named the labels as ZPnnn and ZWnnn (for wordsize). Not just lda ($fa),y stuff, which was possibly conflicting pointer by other routine.. for example. I leave the other methods for True Programmers :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
"s there any other means at all to nicely access the operand by label pointer instead of opcode?"
dont know anything better. possibly you can script this in kickass by generating labels from stuff like:
VAR lda #$00
in 64tass style: var2 = var +1 ;)
btw I'm still guilty of using (fa) (fe), but I keep them now as labels (no $ infront), its just faster to type them out, and I have my own patterns where I use them and what to. |
| Previous - 1 | ... | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | ... | 61 - Next |
