Re: [cc65] Temporary zero-page allocation

From: doynax <doynax1gmail.com>
Date: 2013-10-28 18:16:55
>
> I have never tested something like that, but I think that getting it right
> is
> more work than what it saves. The biggest 6502 assembler program I've
> managed
> in my history was Elite 128. I remember quite some nasty bugs, but no real
> problems with management of zero page variables. Maybe this is why I don't
> rate the problem as really serious. Your mileage may of course vary.
>

Not to worry.. I am quite capable of making a complete mess of even
moderately sized projects, especially when I try to be clever with the
assembly code. The game isn't actually much more than 7k lines or so at the
moment.

This whole discussion stems from me running out of zero-page space and
trying to free some up by moving dozens of temporaries/parameters into the
previously under-utilized zero-page register file. After a week of running
into all sorts of nasty collisions I was hoping there would be a better way.

If you mean .MAX then yes, it has always been evaluated at link time if
> necessary. As is true for any operator in an expression.
>

Must confess that I haven't been able to come up with anything particularly
clean or practical to date. The following kludge is about the best I have
figured out so far:

.macro tmp_top result,p1,p2,p3,p4,p5
 .ifblank p2
    .globalzp .ident(.concat(.string(p1), "_tmp"))
    result := .ident(.concat(.string(p1), "_tmp"))
    .exitmac
 .endif
 .local lhs,rhs
 tmp_top lhs,p1
 tmp_top rhs,p2,p3,p4,p5
 result := .max(lhs,rhs)
.endmac

.mac tmp_func func,space,callee1,callee2,callee3,callee4,callee5
 .local base
 tmp_top base,callee1,callee2,callee3,callee4,callee5
 .globalzp .ident(.concat(.string(func), "_tmp"))
 .ident(.concat(.string(func), "_tmp")) := base+space
.endmac

The idea being that every function declares itself, how much stack space it
needs, and every function it calls via tmp_func. And as output it defines a
label with the same name as the function and a _tmp suffix for use as the
base of the temporary area.

Admittedly this is an awful lot of redundant typing, with joining large
sets of function pointers targets being particularly error prone. Plus the
stack should really be defined top-down instead of bottom-up to allow (say)
the return values from one sub-function to survive past the invocation of
another.

Hm..


> The NES guys are quite ahead when it comes to emulator features. As far as
> I
> know there are even two NES emulators that support cc65 generated debugging
> information.
>
> But unfortunately it looks a lot worse when it comes to other platforms. So
> depending on the platform targeted by the thread starter, this may or may
> not
> be an option
>

Unfortunately it's a C64 project. I fear importing the labels into VICE is
about as far as I've gotten when it comes to symbolic debugging.

I don't suppose anyone has been doing any work on this front for the
breadbox?

Regards,
Johan

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Mon Oct 28 18:17:05 2013

This archive was generated by hypermail 2.1.8 : 2013-10-28 18:17:07 CET