Re: [cc65] HEAP from here to there

From: Greg King <greg.king41verizon.net>
Date: 2009-06-05 19:53:32
From: "Oliver Schmidt"; on Friday, June 05, 2009; 05:28 AM -0400
>
> From: Greg King
> > The boundaries of the heap would be formed by two segments ...
> > Their size would be zero; only their starting addresses
> > would be important...
>
> I must admit that I'm not too happy with your suggestion.  From the
> ld65 perspective, a segment is an entity with a size determined at
> link-time.  That isn't generally true for the heap (nor is it necessary
> or even desirable).  So, the heap just isn't a segment; and therefore,
> your idea seems misuse of the segment paradigm -- which is quite
> confusing to every non-insider...
>
> I'd consider it much more intuitive and straight-forward to have
> symbols for the heap, instead.  Something like this:
>
> SYMBOLS {
>   __STACKSIZE__: value = $800, weak = yes; # 2 Ki stack
>
>   __HEAPORG__: __RAM_LAST__;
> # or alternatively, __BSS_RUN__ + __BSS_SIZE__
>
>   __HEAPEND__: $D000 - __STACKSIZE__;
> }

Your way is more direct (and, easier to understand).  But, I think that my
way is more traditional (LD65 traditional) -- even if it does cause the
edges of the segment paradigm to "fray." ;-)

I think that my way is both more difficult, and easier, to customize.  If a
programmer wanted to force the heap to sit between two absolute addresses,
then your style is easier to edit.  But, if one wanted to put a
specially-named segment between the BSS and the heap, then my style would
let one simply insert that segment's line into the configure-file --
nothing else would need to be changed.

    BSS:   load = RAM, type = bss, define = yes;
    FONT2: load = RAM, type = bss, align = 2048;
    HEAP:  load = RAM, type = bss, optional = yes;

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Fri Jun 5 20:31:38 2009

This archive was generated by hypermail 2.1.8 : 2009-06-05 20:31:40 CEST