Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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
 
... 80 posts hidden. Click here to view all posts....
 
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: 11386
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: 11386
and $XX calls a lisp sub procedure? genious!
2016-06-23 01:30
ChristopherJam

Registered: Aug 2004
Posts: 1409
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: 1409
Quoting Groepaz
and $XX calls a lisp sub procedure? genious!


Damn Greenspun...
2016-06-23 05:46
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)
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: 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 :)
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Guests online: 132
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Coders
1 Axis  (9.8)
2 Graham  (9.8)
3 Lft  (9.8)
4 Crossbow  (9.8)
5 HCL  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.062 sec.