Re: [cc65] Temporary zero-page allocation

From: Payton Byrd <plbyrd1gmail.com>
Date: 2013-10-30 16:15:14
I am immensely interested in a real solution for debugging C code in VICE.
On Oct 30, 2013 10:13 AM, "Christopher Pow" <christopher.s.pow@gmail.com>
wrote:

>
> > 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:15:37 2013

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