Hi Greg, > The boundaries of the heap would be formed by two segments (or, only one in > some targets). They would be placed in different memory areas. Their size > would be zero; only their starting addresses would be important. The distance > between those two addresses would be the heap's size. I must admit that I'm not too happy with your suggestion. From the ld65 perspective a segment is a entity with a size determined at link time. This 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. And those non-insiders tend to already have issues with understanding the linker config (as you can judge easily i.e. from the postings in this thread)... 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__; } Maybe this would be supported by ld65 out-of-the box. Otherwise ld65 might need a slight modification... Best, Oliver ---------------------------------------------------------------------- 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 11:28:39 2009
This archive was generated by hypermail 2.1.8 : 2009-06-05 11:28:41 CEST