Re: Re: [cc65] HEAP from here to there

Uz,

Thanks for your response.

> Maybe, but in most cases this solution is less flexible. The problem is 
> that there are two growing areas, heap and stack. If you make them 
> distinct, each area needs to have some safety overhead.

I agree, but I think the problem is slightly a different one:

Current implementation:
-----------------
BSS (known size)     BSS Segment
-----------------\
HEAP (grows >>>)  \
~~~~~~~~~~~~~~~~~ /  HEAP Segment (not really)
Stack (<< grows) /

All of these *three* areas must be consecutive in the current implementation:
(1) SP is calculated using (__RAM_START__ + __RAM_SIZE__) in crt0
(2) real heap start is calculated using __BSS_RUN__ + __BSS_SIZE__
(3) real heap end is calculated using SP - __STACKSIZE__

IMHO better implementation:

somewhere:
-----------------
BSS (known size)     BSS Segment
-----------------

somewhere else:
-----------------\
HEAP (grows >>>)  \
~~~~~~~~~~~~~~~~~ /  HEAP Segment
Stack (<< grows) /

(1) SP is calculated using (__HEAP_START__ + __HEAP_SIZE__) in crt0
(2) real heap start is __HEAP_START__
(3) real heap end is calculated using SP - __STACKSIZE__

> In the choosen scenario (which is rather common on most platforms), 
> both can grow and a safety area is shared by
> both, which reduces overall memory needs.

This still fulfills your requirements, because stack and heap are both in the HEAP segment. It is identical with the current implementation when all of them are in the (same) RAM area. But it also allows to split up BSS and (heap + stack). IMHO there's no reason to have this dependency from the BSS segmemt in the address calculation.

Or did I miss a point?

Regards

Thomas


----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.