Menu
▾
▴
[sdcc-devel] [ sdcc-Feature Requests-837937 ] better 8051 linker idata & stack placement defaults
|
From: SourceForge.net <no...@so...> - 2003-12-22 15:07:20
|
Feature Requests item #837937, was opened at 2003-11-07 16:23 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=837937&group_id=599 Category: None Group: None Status: Open Priority: 5 Submitted By: Maarten Brock (maartenbrock) Assigned to: Nobody/Anonymous (nobody) Summary: better 8051 linker idata & stack placement defaults Initial Comment: Hi, As mentioned in the docs the linker places the data area as low as possible (which is a good thing) and the stack right on top of it (which is also ok if there is no idata). The idata area is placed at 0x80 by default. Now if you do use idata I think it would be better to locate idata on top of data and to locate the stack on top of idata. Right now I have to play for linker myself and adjust -- idata-loc and --stack-loc by hand every time something changes in the memory layout. Could this please be improved? And now a more daunting task: If one also uses bdata, the data area moves up and ignores the memory of unused register banks. Would it be possible to have the linker also use the space of unused register banks? I understand this complicates things, but a simple greedy algorithm (find the first area where a variable fits) will do I think. There usually are enough variables of only one byte to fill the register bank area to the max. Trying to help improve SDCC, Greetings, Maarten Brock ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2003-12-22 16:07 Message: Logged In: YES user_id=888171 My first attempt at a patch has been submitted under patches. Maarten Brock ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350599&aid=837937&group_id=599 |