| |
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....
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
"I got a plenty of SMC labels like Something=*-1 so my code looks like ANYTHING else but CLEAN because of this :)
How you would create that kind of label touching code? I spent just several hours just because of this..."
I guess its a matter of habit what's comfortable & clean to you. I usually do this:
smod lda #$00
sta $d020
inc smod+1
this keeps the label and the instruction on the same line *-x wont fuck up, since you cant insert extra instruction inbetween, furthermure its obvious where the label points no *+ fucking, and one label is enough to reach lo/hi / instruction.
if the branch is really close then just:
inc $d020
jmp *-3
lda #$03
adc $02
sta $02
bcc *+3
inc $03
but I only use it in very simple cases like this. if you insert an instruction and forget to update the * you're fucked. |
| |
soci
Registered: Sep 2003
Posts: 473 |
Oswald, that was a good example why using *+ and *- is really error prone:
bcc *+3
inc $03
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11113 |
hey, that way debugging never becomes a bore! =) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Oswald, that was a good example why using *+ and *- is really error prone:
bcc *+3
inc $03
*+4, got me there. I use those without knowing what happens, now I got exposed. i never know if the * refers to the instruction or the operand... and just too lazy to think about it for a minute O:-) I only use them to avoid the 125th skip label. |
| |
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..?!) |
| Previous - 1 | ... | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | ... | 61 - Next |
