From: Groepaz (groepaz_at_gmx.net)
Date: 2003-04-24 17:06:45
On Wednesday 23 April 2003 23:56, Ullrich von Bassewitz wrote:
> I've already found this to be a problem with Groepaz NES code.
> Unfortunately, I don't have an idea for a solution that is 1. easy to
> handle and 2. easy to implement. Allowing to define stack and heap in the
> linker config would work, but this would need a complete expression
> evaluation for the linker, so it is not exactly what I would call "easy to
> implement". As it looks now, you will have to live with the existing linker
> and code, provided that no one has a better suggestion.
MEMORY {
[...]
RAM: start = $7FF, size = $c801, define = yes, file = %O;
}
SEGMENTS {
[...]
STACK: load = RAM, type = rw, define = yes;
HEAP: load= RAM, type = rw, define = yes;
}
FEATURES {
[...]
}
SYMBOLS {
[...]
__STACKSIZE__ = $800; # 2K stack
__HEAPSIZE__ = -1 # -1 == all of the remaining space in segment
# maybe to get rid of the -1 kludges, make "all remaining"
# the default when __HEAPSIZE__ is omitted.
}
i fail to see the problem with that :o) you dont need expression evaluation
here (you didnt just wanted to move the dodgy calc-from-bss stuff into the
linker script eh? tsts :=))) and most of whats needed to support this should
be implemented already as i see it... the linker just needs to grab the size
of heap and stack from the "symbols" section and then "load" it like any
other segment. .... actually if you reserve space manually in stack/heap
segment (which is still kinda dodgy) this should work fine with the current
linker as is.
oh and this should even allow to write a quite generic crt0 aswell that can
deal with all kinda memory layouts (no idea how demanded that is though :=P)
gpz
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-04-24 17:13:03 CEST