From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-04-24 23:03:23
On Thu, Apr 24, 2003 at 05:06:45PM +0200, Groepaz wrote:
> 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)
It violates 2.: Needs extensions and is not easy. How is the linker supposed
to know that __STACKSIZE__ defines the size of the stack? This is what I mean
with expressions, a reasonable implementation would need something like
MEMORY {
RAM: start = $7FF, size = $c001, define = yes, file = %O;
STACK: start = __RAM_START__ + __RAM_SIZE__, size = __STACKSIZE__,
define = yes, file = "";
...
}
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
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 23:06:53 CEST