On Thu, Oct 04, 2012 at 03:02:43PM +0100, R. Diez wrote: > > > >> [...] > > >> At the moment, the stack is at the top of the RAM, which makes it hard to > > keep the RAM size flexible. > > > > Why not change the linker script to allocate a sane amount of memory > > space for stack and place this area after the data RAM? This then > > introduces a minimum RAM size that the executable is compatible with. > > Remember, this is just for libgloss-based executables, which are > > likely to be stand alone and not very big. > > I'm not certain what you mean by "data RAM" here. I haven't looked at the > libgloss files for a while, but I think the start-up code does not look at > any stack address specified in the linker script file, but just takes its own > hard-coded RAM size and places the stack pointer at the RAM's top end. > > Furthermore, I generally dislike statements like "a sane amount of memory" > and "likely to be not very big" anyway. I would rather allocate a fixed > amount that libgloss needs to start up, and encourage the application or > Operating System to move the stack as soon as possible after newlib's own > startup, and maybe offer the possibility to reclaim the initial stack space > as malloc memory for the application. And I wouldn't want to make any > assumptions about how big the end application willl be. >
If you want something like that it sounds like you more likely are going to provide your own startup files. IMO, for libgloss, the sane thing is to put the sp at end of ram. If you still really want to do what you propose, why not just define a small enough _board_mem_size and adjust the stack pointer first thing in main? Note though, you'd have to have a naked main, since you will ruin any stack stores that are made in the prologue. But you would have the same problem in your proposed solution anyway. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
