Page 4 of 4
Re: Reimplementing 6502 syntax in ca65
Posted: Tue Nov 26, 2013 10:45 pm
by tepples
Let me translate it into a language that uses slightly more familiar syntax:
Code: Select all
# Guido likes pretty tracebacks better than tail call optimization,
# but another Python implementation might offer it in a future statement
def factorialTimes(x, acc):
if x <= 0:
return acc
else:
return factorialTimes(x - 1, x * acc)
def factorial(x):
return factorialTimes(x, 1)
Or in a fictitious assembly language:
Code: Select all
; Returns X! * A in A
.proc factorialTimes
cpx #0
bne is_nonzero
rts
is_nonzero:
mul x ; A <- A * X
dex
jmp factorialTimes
.endproc
; Returns X! in A
.proc factorial
lda #1
jmp factorialTimes
.endproc
When you return the result of a function call, you can just JMP to the new function instead of doing the equivalent of a JSR immediately followed by RTS. Likewise, macro A calling macro B on the last line of A shouldn't eat up a stack level.
But that's all really beside the point, as these macros aren't very deeply nested, and .addrsize allows the project to go forward.
Re: Reimplementing 6502 syntax in ca65
Posted: Tue Nov 26, 2013 11:48 pm
by Movax12
tepples wrote:macro A calling macro B on the last line of A shouldn't eat up a stack level.
Is see more what you are saying. It is besides the point (Though I think it is a stretch to call it a tail call in a macro.) Regardless, even if the end result of the logic is the same with a goto/loop the macros are just expanded as they are "called" like an inline function. With ca65 at least, there is a stack for things like local symbols and parameter names. Pretty sure it doesn't check for tail calls, though I guess there would be no harm.
Re: Reimplementing 6502 syntax in ca65
Posted: Mon Dec 23, 2013 7:46 pm
by tepples
I found another related deficiency that's white-elephantish even for "normal" uses of ca65.
Code: Select all
; ca65 2.14.0 refuses to recognize "high byte of a zero page
; label" as an expression whose constant value is 0.
.importzp a_zp_label
.ifconst >a_zp_label
.out "zp label high byte is const"
.else
.out "zp label high byte is not const"
.endif
Result:
zp label high byte is not const
Re: Reimplementing 6502 syntax in ca65
Posted: Mon Dec 23, 2013 8:34 pm
by blargg
Does ca65 perhaps support a direct page at a page other than zero, as the 65816 does? That would be nice.
Re: Reimplementing 6502 syntax in ca65
Posted: Mon Dec 23, 2013 8:38 pm
by tepples
I get the same output even when I explicitly exclude 65816 features.
Code: Select all
.p02 ; exclude relocatable direct page of 65816
.importzp a_zp_label
.ifconst >a_zp_label
.out "zp label high byte is const"
.else
.out "zp label high byte is not const"
.endif
Re: Reimplementing 6502 syntax in ca65
Posted: Tue Jun 16, 2015 5:24 am
by Movax12
It's worth adding to this thread that
.addrsize is now part of the main repository, so full implementation of custom instructions as described in this thread is now possible in ca65.
github:
https://github.com/cc65/cc65
Documentation:
http://cc65.github.io/doc/ca65.html#ss10.1
Re: Reimplementing 6502 syntax in ca65
Posted: Mon Sep 30, 2019 2:37 pm
by tepples
Movax12 wrote:I edited the ca65none.s: All labels are now cheap locals. I used .feature ubiquitous_idents due to the fact that ca65 complains about the use of a forced :absolute in my code (says not valid for cpu type).
I filed an issue about this.
Enable all address sizes for CPU none (#939)
(Bumped while revisiting a bunch of my older, smaller projects for
little things)
Re: Reimplementing 6502 syntax in ca65
Posted: Sun Oct 06, 2019 5:26 pm
by strat
Reading through this topic reminded me of a problem I ran into with a Super NES rom hack and ca65. You probably know 65816 handles zeropage like this:
Code: Select all
lda #$1800
tcd
lda $72 ; loads from $1872
I modified part of the game's controller checking routine to shave off a few bytes and tried writing this to load directly from $72 (so as not to waste bytes modifying the directpage register):
Code: Select all
lda $0072 ; whoops, the assembler helpfully cuts off the zeroes and it still becomes a zeropage instruction.
Writing out literal machine code to force a 16-bit read of that 8-bit address got around the issue. I didn't see anything in the ca65 doc to indicate forcing zeropage on a $00xx address could be turned off. This is probably a rare problem (when writing a normal program you would just use "tcd" at will) but it looks like the assembler taking control away from the programmer. :p
Re: Reimplementing 6502 syntax in ca65
Posted: Sun Oct 06, 2019 6:12 pm
by tepples
In stock ca65, you'd force absolute mode with lda a:$72 or far mode with lda f:$72.
Re: Reimplementing 6502 syntax in ca65
Posted: Sun Oct 06, 2019 6:27 pm
by tokumaru
strat wrote:Code: Select all
lda $0072 ; whoops, the assembler helpfully cuts off the zeroes and it still becomes a zeropage instruction.
Even if assemblers used leading zeroes as an indication of an operand's size (AFAIK most don't), you're not supposed to be typing hardcoded address when coding in the first place, as it makes variables hard to trace and reposition, a problem commonly solved with the use of symbols/labels. For this reason, it makes more sense for assemblers to provide a way to force operand sizes that's compatible with symbols as well as with numbers, like ca65 does.