[CSDb] - User Forums - Converting ACME code to Kick Assembler

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Converting ACME code to Kick Assembler

2016-06-19 03:24

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

2016-06-19 05:20

Endurion

Registered: Mar 2007
Posts: 72

= 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.

2016-06-19 06:25

Oswald

Registered: Apr 2002
Posts: 5018

ya. reseta is the addy of #$00 in lda #$00.

and * works.

http://www.theweb.dk/KickAssembler/webhelp/content/ch03s05.html

2016-06-19 07:17

Angel of Death

Registered: Apr 2008
Posts: 210

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? ;)

2016-06-19 08:05

chatGPZ

Registered: Dec 2001
Posts: 11118

thats what you get for having the attention span of a fruit fly

2016-06-19 11:08

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.

2016-06-19 16:46

ChristopherJam

Registered: Aug 2004
Posts: 1378

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

2016-06-19 17:37

Oswald

Registered: Apr 2002
Posts: 5018

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

2016-06-19 19:17

Frantic

Registered: Mar 2003
Posts: 1627

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".

2016-06-19 20:51

Oswald

Registered: Apr 2002
Posts: 5018

"...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.

2016-06-19 21:03

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!

2016-06-19 21:09

Oswald

Registered: Apr 2002
Posts: 5018

.pc = *-1 ? that doesnt sounds good. rather try label = .pc-1

2016-06-19 21:32

Pixman
Account closed

Registered: Dec 2001
Posts: 42

It's invalid. Sorry :P

2016-06-19 22:26

Skate

Registered: Jul 2003
Posts: 490

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.

2016-06-20 05:13

ChristopherJam

Registered: Aug 2004
Posts: 1378

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.

2016-06-20 11:52

chatGPZ

Registered: Dec 2001
Posts: 11118

not sure if someone who finds the original post confusing shouldnt stay with non selfmodding code =P

2016-06-20 11:58

JackAsser

Registered: Jun 2002
Posts: 1989

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

2016-06-20 12:17

chatGPZ

Registered: Dec 2001
Posts: 11118

indeed indeed - jackasser wins the thread :)

2016-06-20 14:23

Dr.j

Registered: Feb 2003
Posts: 276

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 :)

2016-06-20 14:29

TWW

Registered: Jul 2009
Posts: 541

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

2016-06-20 16:30

Oswald

Registered: Apr 2002
Posts: 5018

jacky's note is for beginners. big boys always use the type thats best suitd.

2016-06-20 16:58

chatGPZ

Registered: Dec 2001
Posts: 11118

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) :)

2016-06-20 18:31

JackAsser

Registered: Jun 2002
Posts: 1989

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.

2016-06-20 18:54

Krill

Registered: Apr 2002
Posts: 2845

Interruptible interrupts - the High Art of C-64 coding. :D

2016-06-20 19:54

Oswald

Registered: Apr 2002
Posts: 5018

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.

2016-06-20 19:56

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.

2016-06-20 20:08

JackAsser

Registered: Jun 2002
Posts: 1989

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!

2016-06-20 20:27

chatGPZ

Registered: Dec 2001
Posts: 11118

how to point the label to the second byte of the argument? ie the highbyte of an absolute address?

2016-06-20 20:43

JackAsser

Registered: Jun 2002
Posts: 1989

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

2016-06-20 20:49

chatGPZ

Registered: Dec 2001
Posts: 11118

hehe, that kinda defeats the whole new syntax thing though =)

2016-06-20 20:53

Count Zero

Registered: Jan 2003
Posts: 1825

xreg-1 == areg+2 I'd say!

2016-06-20 20:56

JackAsser

Registered: Jun 2002
Posts: 1989

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

2016-06-20 21:05

chatGPZ

Registered: Dec 2001
Posts: 11118

args. operators that change their meaning depending on what labels come after them? /o\

2016-06-20 21:05

Oswald

Registered: Apr 2002
Posts: 5018

very neat suggestions. but sta >addr would conflict with normal usage of ><

2016-06-20 21:06

Oswald

Registered: Apr 2002
Posts: 5018

how about sta addr> and sta addr<

2016-06-20 21:20

Krill

Registered: Apr 2002
Posts: 2845

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 do

store: sta $1234
[...]
stx SELFMODLO(store); set lo-byte of argument address
sty SELFMODHI(store); set hi-byte of argument address

2016-06-20 22:05

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
}

myRoutine: {
	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.

2016-06-20 22:29

Skate

Registered: Jul 2003
Posts: 490

Slammer, I liked that syntax. I'd definitely use it.

2016-06-21 06:08

Bitbreaker

Registered: Oct 2002
Posts: 500

These are the coder's problems when we wait for the graphics to be done.

2016-06-21 06:13

ChristopherJam

Registered: Aug 2004
Posts: 1378

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)

2016-06-21 07:44

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 :-)

2016-06-21 08:44

Bitbreaker

Registered: Oct 2002
Posts: 500

And those many choices will keep people away from finishing their productions, because they are stuck in circlejerks about syntactic sugar :-D

2016-06-21 10:17

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)!

2016-06-21 13:04

Krill

Registered: Apr 2002
Posts: 2845

Quoting Slammer

- Use // instead of ; for comments

2016-06-21 13:51

TWW

Registered: Jul 2009
Posts: 541

Quoting ChristopherJam

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.

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.

2016-06-21 14:52

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...

2016-06-21 14:58

chatGPZ

Registered: Dec 2001
Posts: 11118

for some strange reason for loops work just fine in any other assembler though =)

2016-06-21 15:10

Slammer

Registered: Feb 2004
Posts: 416

Quoting Groepaz

for some strange reason for loops work just fine in any other assembler though =)

Would it be a 'proper' assembler otherwise?

2016-06-21 15:12

chatGPZ

Registered: Dec 2001
Posts: 11118

would it also use regular braces instead of this annoying [ ] stuff? :)

2016-06-21 15:16

Slammer

Registered: Feb 2004
Posts: 416

Quoting Groepaz

would it also use regular braces instead of this annoying [ ] stuff? :)

Sorry, I don't understand your question, please explain.

2016-06-21 16:12

Oswald

Registered: Apr 2002
Posts: 5018

2016-06-21 17:10

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,....

2016-06-21 17:52

chatGPZ

Registered: Dec 2001
Posts: 11118

cute :)

2016-06-21 19:24

TWW

Registered: Jul 2009
Posts: 541

Quote:

LOL!

Awesome thread.

2016-06-22 06:04

Bitbreaker

Registered: Oct 2002
Posts: 500

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?

2016-06-22 07:05

Krill

Registered: Apr 2002
Posts: 2845

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? :)

2016-06-22 08:41

Dr.j

Registered: Feb 2003
Posts: 276

what Bitbreaker wrote! every word i have to agree for 100% !

2016-06-22 09:00

ChristopherJam

Registered: Aug 2004
Posts: 1378

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

2016-06-22 09:34

Bitbreaker

Registered: Oct 2002
Posts: 500

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.

2016-06-22 09:36

ChristopherJam

Registered: Aug 2004
Posts: 1378

Fair point.

2016-06-22 09:42

Krill

Registered: Apr 2002
Posts: 2845

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.

2016-06-22 10:24

Peacemaker

Registered: Sep 2004
Posts: 243

some talk about coding, the others actualy code =)

2016-06-22 11:07

Krill

Registered: Apr 2002
Posts: 2845

Which is entirely mutually exclusive, as everybody knows. Now those who don't contribute to this thread, kindly fuck off.

2016-06-22 11:12

Peacemaker

Registered: Sep 2004
Posts: 243

Krill, dont be so rude =)

2016-06-22 11:20

ChristopherJam

Registered: Aug 2004
Posts: 1378

Quoting Krill

Also 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.

2016-06-22 11:46

chatGPZ

Registered: Dec 2001
Posts: 11118

Quote:

Which is entirely mutually exclusive, as everybody knows.

loader fixed up for release yet? :=)

2016-06-22 12:35

Angel of Death

Registered: Apr 2008
Posts: 210

Quoting Slammer

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.

I'm off. Byebye, you bunch of cynical old b@stards! ;D

2016-06-22 14:57

Krill

Registered: Apr 2002
Posts: 2845

Peacemaker: Yeah sorry, was a bit annoyed. :)

Quoting Groepaz

Quote:
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. :)

2016-06-22 16:56

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 :)

2016-06-22 17:08

Burglar

Registered: Dec 2004
Posts: 1031

foo lda table
    sta $d020
    inc foo + 1

there, fixed it for you ;)

2016-06-22 17:25

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 ;)

2016-06-22 17:32

chatGPZ

Registered: Dec 2001
Posts: 11118

hooray for antioptimization techniques :o)

2016-06-22 17:40

Burglar

Registered: Dec 2004
Posts: 1031

no sane coder would place their table at $10ff ;)

and, yes, thank fuck for edit :)

2016-06-22 17:42

Oswald

Registered: Apr 2002
Posts: 5018

"This immediately parses, in my head, as self modifying code. No need for assembler-masturbation"

+100000000

2016-06-22 17:43

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.

2016-06-22 17:44

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

2016-06-22 19:58

ChristopherJam

Registered: Aug 2004
Posts: 1378

.align? Bah, all you need is .dsb <-*,0 ;-)

2016-06-22 20:12

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.

2016-06-22 20:29

chatGPZ

Registered: Dec 2001
Posts: 11118

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!

2016-06-22 20:46

Perplex

Registered: Feb 2009
Posts: 254

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

2016-06-22 21:29

chatGPZ

Registered: Dec 2001
Posts: 11118

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\\

2016-06-22 21:29

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 :)

2016-06-22 21:33

chatGPZ

Registered: Dec 2001
Posts: 11118

you could simply omit ALL $ea bytes in the output!

2016-06-22 21:48

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.

2016-06-23 00:41

chatGPZ

Registered: Dec 2001
Posts: 11118

and $XX calls a lisp sub procedure? genious!

2016-06-23 01:30

ChristopherJam

Registered: Aug 2004
Posts: 1378

Quoting Perplex

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

Glad someone noticed!

2016-06-23 01:31

ChristopherJam

Registered: Aug 2004
Posts: 1378

Quoting Groepaz

and $XX calls a lisp sub procedure? genious!

Damn Greenspun...

2016-06-23 05:46

Oswald

Registered: Apr 2002
Posts: 5018

.dsb <-*,0

awesome. never thought of doing it like that. had a 3 line version for native tasm. (dont ask what it was)

2016-06-23 06:32

Slammer

Registered: Feb 2004
Posts: 416

Quoting Krill

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? :)

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 :-)

2016-06-24 20:00

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 [].

2016-06-29 00:44

Krill

Registered: Apr 2002
Posts: 2845

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 :)

Refresh

Subscribe to this thread: