| |
Pixman
Account closed
Registered: Dec 2001
Posts: 42 |
Converting ACME code to Kick Assembler
In this code there are some confusing lines (since there are no proper ACME manuals):
http://codebase64.org/doku.php?id=base:double_irq
lda #$00 ;Reload A,X,and Y
reseta1 = *-1 ;registers
ldx #$00
resetx1 = *-1
ldy #$00
resety1 = *-1
Someone on #c-64 told me = is for the current Program Counter.
But there is no equivalent to this in Kick Assembler.
Solve it with branches?
I seriously have no idea how to fix this problem.
Any suggestions?
Tnx,
Pix |
|
| |
Endurion
Registered: Mar 2007
Posts: 73 |
= sets a label's value. * = current program Counter
so reseta1 is set to the current program Counter - 1
I can't believe Kick Ass wouldn't have something similar, that's a quite essential Feature. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
ya. reseta is the addy of #$00 in lda #$00.
and * works.
http://www.theweb.dk/KickAssembler/webhelp/content/ch03s05.html |
| |
Angel of Death
Registered: Apr 2008
Posts: 211 |
Ehmm... This has nothing to do with ACME itself. This is one of the oldest tricks there are used since the very first assemblers were around.
And the manual provided with ACME is fine and readable, so...
Are you sure you are ready for kickassembler yet? ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
thats what you get for having the attention span of a fruit fly |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
The syntax is not that different.
- Use // instead of ; for comments
- Use : at the end of labels.
- Use .label x=*+1 when you want to define a user defined label
- In older Kick Ass versions use .pc=$1000 instead of *=$1000
You could use the converter by Noice. Copy-paste your example into this form and get a converted output: http://tasmtokickass.insoft.se
The output is KickAss3.x but will also work in 4.x, and will work fine for your purpose.
Feel free to join https://www.facebook.com/groups/RetroAssembler/
A lot of the same people who hang around on CSDb is also is on RetroAssembler, but the discussion is a bit more friendly. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Interesting coding style. Personally I tend to express that pattern like this, albeit with the disadvantage of having to add the +1s if I move to SMC from (eg) zero page vars.
sta reseta1+1 ;Preserve A,X and Y
stx resetx1+1 ;registers
sty resety1+1 ;via self modifying code
...
reseta1
lda #$00 ;Reload A,X,and Y
resetx1 ;registers
ldx #$00
resety1
ldy #$00
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Interesting coding style. Personally I tend to express that pattern like this, albeit with the disadvantage of having to add the +1s if I move to SMC from (eg) zero page vars.
sta reseta1+1 ;Preserve A,X and Y
stx resetx1+1 ;registers
sty resety1+1 ;via self modifying code
...
reseta1
lda #$00 ;Reload A,X,and Y
resetx1 ;registers
ldx #$00
resety1
ldy #$00
I do the same. I think its more readable. just I put the labels infront of the instructions. moving from zp changes a lot in the other case aswell. its a small issue.
sta reseta1+1 ;Preserve A,X and Y
stx resetx1+1 ;registers
sty resety1+1 ;via self modifying code
...
reseta1 lda #$00 ;Reload A,X,and Y registers
resetx1 ldx #$00
resety1 ldy #$00
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
In my case I tend to do similar to the original example, except putting it before the instruction rather than after:
myvariable = *+1
lda #$ff
Having that *+1 stuff at the line before an instruction immediately tells me that this is about self modifying code rather than being a program flow label (e.g. a label that you branch/jump to). Not saying that this is "the best way to do it". Just explicating why I do it the way I do.
...and, doing it this way, I don't have to put "+1" and stuff after the labels when accessing it. This means that if I change a variable from being stored in a "data segment" (so to speak) to being stored in (selfmodifying) code instead, I don't have to change all variable references to "sta myvariable+1" but I can just keep on using "sta myvariable". |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"...and, doing it this way, I don't have to put "+1" and stuff after the labels when accessing it."
when you put +1 after the labels its an implied sign that your code deals with self modify there. otherwise its just a label there and there's no way to tell if its a var or smc.
also you get even more clutter in the way of clean code when you want to selfmod 16bit abs value.
but its a matter of taste. |
| |
Pixman
Account closed
Registered: Dec 2001
Posts: 42 |
Thanks for your help, Oswald.
But *-1 doesn't work. I found a solution, though:
.pc = *-1
Compiles!
€dit: Assembles, sorry
Yay! |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
.pc = *-1 ? that doesnt sounds good. rather try label = .pc-1 |
| |
Pixman
Account closed
Registered: Dec 2001
Posts: 42 |
It's invalid. Sorry :P |
| |
Skate
Registered: Jul 2003
Posts: 494 |
I often use;
lda #$00 : reseta1 = *-1
ldx #$00 : resetx1 = *-1
ldy #$00 : resety1 = *-1
instead of using a new line. That's the only case i find ":" useful. No additional lines wasted. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Yeah, label on the same line's a good way to avoid accidentally separating the target instruction from the label later on; I learned that one the hard way. Never use the same label for both self-modifying target and for loop start LOL
I used to put "RNA" in the name as well as an additional reminder, but grepping my sources it looks like I've gotten out of that particular habit. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
not sure if someone who finds the original post confusing shouldnt stay with non selfmodding code =P |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: not sure if someone who finds the original post confusing shouldnt stay with non selfmodding code =P
And then you start allowing irqs in irqs and this selfmodding stuff will bite you anyway. :) Always if you're not cycle critical please do:
pha
txa
pha
tya
pha
lda $1
pha
...
pla
sta $1
pla
tay
pla
tax
pla
rti
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
indeed indeed - jackasser wins the thread :) |
| |
Dr.j
Registered: Feb 2003
Posts: 277 |
sorry for the lame comment but i find the
"reseta1 = *-1" is much less "sexier" than *+1
for me the first is still confusing , and the latter is better and much stright forward and replace the other. when i am lazy and don't have time for labeling stuff i just use the direct approach:
a0: lda $0400,x
lda #$00
sta a0+1
lda #$04
sta a0+2 or what-so-ever , the old classic way always wins :) |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Quote: And then you start allowing irqs in irqs and this selfmodding stuff will bite you anyway. :) Always if you're not cycle critical please do:
pha
txa
pha
tya
pha
lda $1
pha
...
pla
sta $1
pla
tay
pla
tax
pla
rti
+1 |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
jacky's note is for beginners. big boys always use the type thats best suitd. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
for the most part "big boys" know when a certain optimization is useful and when its not (and most of the times THIS optimization isnt useful nor required at all) :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: for the most part "big boys" know when a certain optimization is useful and when its not (and most of the times THIS optimization isnt useful nor required at all) :)
Indeed. The selfmod bites me everytime we link and HCL slaps my fingers for not saving $1-state when loading under io, or when I all of a sudden want to to some heavylifting in the IRQ and add a cli to make sure the music don't stop. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Interruptible interrupts - the High Art of C-64 coding. :D |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: for the most part "big boys" know when a certain optimization is useful and when its not (and most of the times THIS optimization isnt useful nor required at all) :)
except when horizontal timing asks for faster irq entry. or you have a lot of irq. fex a 4x4 timing with lot of pha and $01 saving would suck big time. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Whether you like to make selfmodifying code on irq changes or not, this is still an interesting topic if you see it as a general discussion of how you can make selfmodifying code.
The posts from Skate and ChristopherJam makes a lot of sence, doing onelines with the format:[label] mnemonic argument [argumentLabel] Having another way of writing labels pointing to arguments can make the code more readable, but still it's alot to write for doing it. So I made an implementation that suports labelling the start of the argument instead of the instruction. The syntax looks like this on the irq-example:
sta areg
stx xreg
sty yreg
...
lda areg:#$00
ldx xreg:#$00
ldy yreg:#$00
I will give it a couple of days before releasing to see if its really sound and make some tests, but so far it looks good to me, so thanks to Skate and Christopher for the inspiration. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Whether you like to make selfmodifying code on irq changes or not, this is still an interesting topic if you see it as a general discussion of how you can make selfmodifying code.
The posts from Skate and ChristopherJam makes a lot of sence, doing onelines with the format:[label] mnemonic argument [argumentLabel] Having another way of writing labels pointing to arguments can make the code more readable, but still it's alot to write for doing it. So I made an implementation that suports labelling the start of the argument instead of the instruction. The syntax looks like this on the irq-example:
sta areg
stx xreg
sty yreg
...
lda areg:#$00
ldx xreg:#$00
ldy yreg:#$00
I will give it a couple of days before releasing to see if its really sound and make some tests, but so far it looks good to me, so thanks to Skate and Christopher for the inspiration.
That is a quite awesome syntax in my opinion. Good work! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
how to point the label to the second byte of the argument? ie the highbyte of an absolute address? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: how to point the label to the second byte of the argument? ie the highbyte of an absolute address?
label+1 :D :D :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
hehe, that kinda defeats the whole new syntax thing though =) |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
xreg-1 == areg+2 I'd say! |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: hehe, that kinda defeats the whole new syntax thing though =)
Yeah, indeed.
Suggestion:
; 8-bit argument
sta arg
lda arg:#$00
; 16-bit argument
lda #<$c020
sta <addr
lda #>$c020
sta >addr
...
bit addr:$0000
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
args. operators that change their meaning depending on what labels come after them? /o\ |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
very neat suggestions. but sta >addr would conflict with normal usage of >< |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
how about sta addr> and sta addr< |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
To be honest, this looks like syntactical sachharin to me, creating more problems than it solves. A 6502 op-code is always one byte, its first argument byte always one byte later, and the second two. I see no problem with the classical way of doing it, e.g.store: sta $1234
[...]
stx store + 1; set lo-byte of argument address
sty store + 2; set hi-byte of argument address To make it a bit fancier (and cleaner, depending on taste), use macros, so you can dostore: sta $1234
[...]
stx SELFMODLO(store); set lo-byte of argument address
sty SELFMODHI(store); set hi-byte of argument address |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
I don't mind writing +1 at the end of the label reference, if we should do that better it must only be one char since +1 is only two.
I see alot of possibilities in this:
- It makes a label point to the argument, so you can easier switch between 'normal label before byte directive' and 'selfmodifying code'.
- You don't have to reuse a loop label as an argument label, you can do: loop: lda.a memPos:$0000 - When a label is inside a library routine it might be good that the caller don't know what the implmentations is behind it:myRoutine: {
lda color
sta $d020
rts
color: byte 0
}ormyRoutine: {
lda color:#$00
sta $d020
rts
}- Visually, It might make it easier to find your loop labels as there are fewer labels on the left of the screen. (Again it might make it harder to find you argument labels since they don't start at column 0)
- It makes it clearer what the purpose of the label is.
- Users don't have to use the syntax, so it don't cripple anybodys codingstyle - you can always use good old +2 if you want to.
- It works nicely without +1 for all one byte arguments
I think its a matter of style, and it have to be tried in practise to figure out if its good or not and taste is individual. You never improve your style if you don't try something new.
Krill: Indeed it is syntactic sugar, since you could do the same by combining a mnemonic an a user defined label. |
| |
Skate
Registered: Jul 2003
Posts: 494 |
Slammer, I liked that syntax. I'd definitely use it. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
These are the coder's problems when we wait for the graphics to be done. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I like that syntax a lot.
Happy to be using +1 to get to the high byte; I already do that for zero page pointers anyway, this way I'd not be using +0/+1 for zp, +1/+2 for SMC.
It removes the overloading where sometimes +1 means SMC and sometimes it means high byte.
(oh, and a belated +1 for JackAsser's comment that newbies should be using stack rather than SMC anyway. Optionally only save what you're going to trash too - applies as much to AXY as it does to $01) |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
An argument label could generate 3 labels: lda.a memPos:$1000 // Generates: memPos, memPosLo, memPosHi This enforces a special naming convention, which I don't like (It should be up to the user).
We could also make fields on labels. So you could do:sta memPos.lo
stx memPos.hi
...
lda.a memPos:$1000 That would remove the need for +1. There are alot of possibilities :-) |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
And those many choices will keep people away from finishing their productions, because they are stuck in circlejerks about syntactic sugar :-D |
| |
Pixman
Account closed
Registered: Dec 2001
Posts: 42 |
FINALLY! It works, thanks to NOICE's Tasm to KickAss-converter.
Output looks like this:
lda #$00 //Reload A,X,and Y
.label reseta1 = *-1 //registers
ldx #$00
.label resetx1 = *-1
ldy #$00
.label resety1 = *-1
Works perfectly and smooth.
Thanks for all the help (and fish)! |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Slammer- Use // instead of ; for comments  |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Quoting ChristopherJamHappy to be using +1 to get to the high byte; I already do that for zero page pointers anyway, this way I'd not be using +0/+1 for zp, +1/+2 for SMC.
I use:
.var ZP = $02
.const ZP_Vector = ZP .eval ZP = ZP + 2
.const ZP_VectorLo = ZP_Vector
.const ZP_VectorHi = ZP_Vector+1
And then use like this:
lda <Destination
sta ZP_VectorLo
lda >Destination
sta ZP_VectorHi
jmp (ZP_Vector)
Assuming I understood correctly.
Edit: And if You also have defined some 16 bit pseudos You can do: : CWA destination ; ZP_Vector and forget all about lo and hibytes. |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Krill: Because if ; where comments you wouldn't get far with high level for loops.
.for(var i=0;i<8;i++) Ooops... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
for some strange reason for loops work just fine in any other assembler though =) |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Quoting Groepazfor some strange reason for loops work just fine in any other assembler though =)
Would it be a 'proper' assembler otherwise? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
would it also use regular braces instead of this annoying [ ] stuff? :) |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Quoting Groepazwould it also use regular braces instead of this annoying [ ] stuff? :)
Sorry, I don't understand your question, please explain. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
 |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Better get a bigger pack, my guess is that this might go on for days with 1. The usual namedropping argument, 2. The incbin speech, 3. The 'its so stupid' argumentation, 4. Remarks of what he will do to himself. 5. The 'its improper' argument,.... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
cute :) |
| |
TWW
Registered: Jul 2009
Posts: 545 |
Quote:
LOL!
Awesome thread. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Seriously, if someone hurts oneself with self modifying code, or addressing a low or highbyte of some mnemonic, one better stops claiming to be a coder. This is not rocket science at all, no matter if label = * + 1, label+1, label-1, labelHi or labelLo is used. It is one of the very basics. It is like discussing if one should use a label or do a bcs *+5. Both work, and no one cares, can we proceed please? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
This thread is now about specialised new syntax for a common use-case, a-okay to discuss. Now here are my 2 cents:sta <[memPos]
stx >[memPos]
...
lda memPos:$1000 While i like the label for the argument as proposed by Slammer, i also like fairly standard syntax and semantics as known from various assemblers and also other platforms' standard assembly syntax.
The [] operator here acts similarly to x86 Intel assembly: it dereferences an address. Normally, < and > would operate on the memory address a label represents, but here, we want to operate on the memory where the address itself resides. The label refers to a pointer and is an implicit pointer itself, after all.
Now, i have a hunch that this collides with Kickass' funky syntax (or parser, for that matter), but we're discussing pure theory here now, aren't we? :) |
| |
Dr.j
Registered: Feb 2003
Posts: 277 |
what Bitbreaker wrote! every word i have to agree for 100% ! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting Bitbreaker no one cares, can we proceed please?
Well, thread is evidence to the contrary, and no-one's forcing you to read it..
/gets back to loader coding regardless |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
You know, i would love to see people coding on serious stuff and not just wasting their time on such basics. There's X this year, and i want some serious demos to clash there. But this thread gives me the feeling that everybody has either their demo finished or not even started yet. That would be sad. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Fair point. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Seriously, dude. If people feel like discussing things, just let them. Annoying them won't make them drop it. Also it's not like most people can sneak-code at work, but many more can discuss in forums at work. |
| |
Peacemaker
Registered: Sep 2004
Posts: 275 |
some talk about coding, the others actualy code =) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Which is entirely mutually exclusive, as everybody knows. Now those who don't contribute to this thread, kindly fuck off. |
| |
Peacemaker
Registered: Sep 2004
Posts: 275 |
Krill, dont be so rude =) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting KrillAlso it's not like most people can sneak-code at work, but many more can discuss in forums at work.
Very true. Besides, I can shitpost when I'm in bed or having breakfast; getting some code done actually requires a chunk of time to get my brain into gear. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Which is entirely mutually exclusive, as everybody knows.
loader fixed up for release yet? :=) |
| |
Angel of Death
Registered: Apr 2008
Posts: 211 |
Quoting SlammerFeel free to join https://www.facebook.com/groups/RetroAssembler/
A lot of the same people who hang around on CSDb is also is on RetroAssembler, but the discussion is a bit more friendly.
I'm off. Byebye, you bunch of cynical old b@stards! ;D |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Peacemaker: Yeah sorry, was a bit annoyed. :)
Quoting GroepazQuote:Which is entirely mutually exclusive, as everybody knows.
loader fixed up for release yet? :=) Mostly. But it's more fun to do other stuff like Zoompinski [512 bytes] instead of boring patchwork. :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I still don't get what is wrong with the de-facto way of doing self-modifying code:
foo ldx#0
lda table,x
sta $d020
inc foo + 1
This immediately parses, in my head, as self modifying code. No need for assembler-masturbation, coming up with weird syntax that is just meant for assembler writers to feel cool.
We used to be happy with this, no need for braces, brackets, macro's, superfluous assignments, scripting languages, +1/+2 is enough.
God dammit :) |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
foo lda table
sta $d020
inc foo + 1
there, fixed it for you ;) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
No you didn't.
table = $10ff
Now we need:
.macro inc_table
inc \1 + 1
bne +
inc \1 + 2
+
.endm
foo lda table
sta $d020
#inc_table foo
Which kind of defeats the purpose of my rant.
And thank fuck for editing posts ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
hooray for antioptimization techniques :o) |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
no sane coder would place their table at $10ff ;)
and, yes, thank fuck for edit :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"This immediately parses, in my head, as self modifying code. No need for assembler-masturbation"
+100000000 |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I'm sure this can be optimized even further:
; // \1 is arg 0
.macro inc_mem {
.if (code_or_table_crosses_page(\1) {
.macro bar {
inc \1 + 1
bne +
inc \1 + 2
} else {
.macro bar {
inc \1 + 1
}
return bar;
}
All I need to do now is figure out the `code_or_table_crosses_page` function/macro. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: no sane coder would place their table at $10ff ;)
and, yes, thank fuck for edit :)
I would, unknowingly, which things like .align solve, one of the actual useful extensions to TA |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
.align? Bah, all you need is .dsb <-*,0 ;-) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Looks like that just fills unused mem with 00. My assembler optimizes NOP's and BIT $EA away for shorter and faster code, so BRK would just confuse it. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:My assembler optimizes NOP's and BIT $EA away for shorter and faster code
sounds like a great feature to have - enabled by default! |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Quoting ChristopherJam.dsb <-*,0 ;-)
What I like about this one is that it assembles just fine with the smiley included. Unless you're using KA of course. // Insert apropriate smiley here |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:What I like about this one is that it assembles just fine with the smiley included. Unless you're using KA of course.
//O\\ |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: Quote:My assembler optimizes NOP's and BIT $EA away for shorter and faster code
sounds like a great feature to have - enabled by default!
Of course it will be enabled by default, is there any other way?
You might be able to disable it with a convoluted mix of C++'14, LIPS, Brainfuck and a few others, I'm still working on a completely fucked up syntax ;)
Command line options won't help either, those will just screw with other command line options in a completely non-logical way.
Crap, maybe I should I actually write this, sounds like fun :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
you could simply omit ALL $ea bytes in the output! |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quote: you could simply omit ALL $ea bytes in the output!
That's the basic operating mode, also $24, wouldn't be the first time some lamer wrote `BIT $24` while that clearly takes bytes and more importantly, cycles.
And JMP $ea31 would become JMP $xx31, almost missed that one. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
and $XX calls a lisp sub procedure? genious! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting PerplexQuoting ChristopherJam.dsb <-*,0 ;-)
What I like about this one is that it assembles just fine with the smiley included. Unless you're using KA of course. // Insert apropriate smiley here
Glad someone noticed! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting Groepazand $XX calls a lisp sub procedure? genious!
Damn Greenspun... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
.dsb <-*,0
awesome. never thought of doing it like that. had a 3 line version for native tasm. (dont ask what it was) |
| |
Slammer
Registered: Feb 2004
Posts: 416 |
Quoting KrillThis thread is now about specialised new syntax for a common use-case, a-okay to discuss. Now here are my 2 cents:sta <[memPos]
stx >[memPos]
...
lda memPos:$1000 While i like the label for the argument as proposed by Slammer, i also like fairly standard syntax and semantics as known from various assemblers and also other platforms' standard assembly syntax.
The [] operator here acts similarly to x86 Intel assembly: it dereferences an address. Normally, < and > would operate on the memory address a label represents, but here, we want to operate on the memory where the address itself resides. The label refers to a pointer and is an implicit pointer itself, after all.
Now, i have a hunch that this collides with Kickass' funky syntax (or parser, for that matter), but we're discussing pure theory here now, aren't we? :)
No collisions. Things like that could be achieved by a grammar rule for less than and braces combined (<[ID] or something) and a precedence rule. But yes, I guess it is purely theoretical.
Good to see you are having fun guys :-) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Sure had some fun, sorry ;)
But back to the topic at hand: a syntax like <[foo] to me parses as indexing, like in C, Java, Python and others. It also adds more operator overloading, which in my opinion isn't a good idea. Just look at current C++: you need to join a monastery for thirty years just to study it properly.
So I would suggest being very explicit about it, using for example Python-like decorators, or just using good old +1/+2 which everyone can understand (which obviously has my preference).
Oh, and by the way, braces are {}, brackets are []. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Compyx<[foo] to me parses as indexing, like in C, Java, Python and others. It also adds more operator overloading Brackets for dereferencing is a pretty old concept in various assembly languages, and possibly pre-dates C and all its descendants (sorry, too late/lazy now to look it up). Plus in assembly, array subscripts are expressed by +/- and not brackets, as you know. :) And it's not really overloading operators, it's modifying them. Or simply using distinct operators, if thought as <symbol vs <[symbol]. But it seems like wordier operators (or pseudo-ops in asm jargon) are preferred by Slammer. So yeah, symbol.lo and symbol.hi, fine enough. And +1/+2 is fine enough alright, but that's not the point here :) |
