Re: [cc65] Temporary zero-page allocation

From: Christopher Pow <christopher.s.pow1gmail.com>
Date: 2013-10-30 16:12:56
> 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?

I attempted to reply to this before but it seems to have been lost or
rejected.  A long while ago I implemented VICE support with NESICIDE, which
allowed symbolic debugging of C64 projects.  I haven't done much with it
though because there seemed to be a diminishing interest.  I would be happy
to dust it off and polish it if there is renewed interest.  I don't know
what "breadbox" is...


On Mon, Oct 28, 2013 at 12:16 PM, doynax <doynax@gmail.com> wrote:

> 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 Wed Oct 30 16:13:09 2013

This archive was generated by hypermail 2.1.8 : 2013-10-30 16:13:11 CET