| |
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 |
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. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11108 |
Quote:the problem with your debug code is kickass, it shouldnt define the conditinal code sections as scopes automagically.
noooooooo /o\ |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
I have a suggestion to kickass developers.
I think there is atleast 3 possible ways to deal with scopes (if you want to take my note on future versions of kickass)
The first one is a dirty addition:
{ // This is a scope
}
#{ // This one is unscoped
}
It could be also "-{" or "{{" instead of "#{" or such, you got the idea. Will be treated as same level as parent scope or main.
The another method could be a Global assignment to a label/var/constant definition:
.global label yesbox=$1234
...and "yesbox" could be then accessible from anywhere the whole source file, visible to all scopes. That's not standard assembly, but is kickassembler syntax any standard assembly anymore at all? :)
Then the third idea:
.scopeless (or .disable_scoping)
...and all scopes below this line would be treated as non-scopes, until .enable_scoping is reached to enable
Shouldn't be hard to implement in future version kickass and neither would break the current codings made with kickass i guess? |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Soci: Thanks, Its corrected in the new version 3.39 just released.
Agemixer: Thanks. If you join the facebook group (https://www.facebook.com/groups/RetroAssembler/) you will get access to the official Kick Assembler Wish List, where you can enter your ideas. It's also a good place for discussing ideas.
I don't know if you have noticed, but you can enter normal scopes like this:
Function1: {
col: lda #01
sta $d020
rts
}
Function2: {
inc Function1.col+1
rts
}
This will ofcause not solve the if-problem. |
| Previous - 1 | ... | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | ... | 61 - Next |
