| |
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 |
"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: 11100 |
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. |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
Because i haven't found any examples how to produce C64 ascii with kickassembler, here is mine:
.function pet2asc(p) { .eval p = [ p>$40? p+=$80 : p ] .return [ p<$20? p^$40 : p ] }
.macro asctxt(str) { .fill str.size(), pet2asc(str.charAt(i)) }
.macro asctxtCR(str) { :asctxt(str) .byte $0d }
ldx #$00
loop: lda text,x
beq end
jsr $ffd2
inx
bne loop
end: rts
text: // C64 ascii
.byte 5 // color = white
.byte 147 // clr+home
.byte 9,14,8 // case change: enable C= + shift, set locase, disable
:asctxt("Hello World!")
:asctxtCR(" 1,2,3,4...")
:asctxtCR("")
:asctxt("The quick brown fox ")
:asctxtCR("jumps over the lazy dog")
.byte 0 |
| |
Agemixer
Registered: Dec 2002
Posts: 38 |
Thanks Slammer |
| |
Murphy
Registered: Jul 2006
Posts: 10 |
Slammer: Thanks for this awesome assembler!
Support of |= (and &=) operators are planned? |
| Previous - 1 | ... | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | ... | 61 - Next |
