Re: [cc65] Temporary zero-page allocation

From: Christopher Pow <christopher.s.pow1gmail.com>
Date: 2013-10-30 17:10:03
It's not so much "in VICE" as it is "in NESICIDE, which uses the
remote monitor a running VICE x64sc instance".

On Wed, Oct 30, 2013 at 10:15 AM, Payton Byrd <plbyrd@gmail.com> wrote:
> 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 17:10:14 2013

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