We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
For the '51 compilers/linkers evaluate which data/idata slots can be overlaid. I have to save 3 slots to make room for a new feature. Is there a way to make the linker show the tree in a less cryptic way than by module (i.e. by function) ? Have fun, Erik
Ok, sorry BUT: (edited for space) ?PR?_SEN?UPC 0036H 0004H +--> ?PR?WAI?UPX +--> ?PR?_WRI?UPXA +--> ?PR?FIN?UPX +--> ?PR?DEC?UPCD +--> ?PR?_PAU?FQ1 SEN uses 2 bytes of DATA, which of the rest is using 4 ? That, Horatio, is the question.
What are the arguments and local variables of this function and what are their data types? Jon
We are way past the subject: "WHICH of the functions sharing this (I)DATA space is the one that uses the full count". Of course I know what the local variables are, but when 47 functions share the same space it is quite tedious to look at all 47 to find out which one to analyze to see if you can find a workaround to reduce (I)DATA use. The abbreviated list in my posting 2 levels up represent a page of functions sharing the same (I)DATA space not just 4 Erik
We are way past the subject: "WHICH of the functions sharing this (I)DATA space is the one that uses the full count". Of course I know what the local variables are, but when 47 functions share the same space it is quite tedious to look at all 47 to find out which one to analyze to see if you can find a workaround to reduce (I)DATA use. The abbreviated list in my posting 2 levels up represent a page of functions sharing the same (I)DATA space not just 4 I you misunderstand the information that is presented in the call tree. The LENGTH is NOT the length of the DATA space used by the functions that are called. It is the size of the function indicated. Perhaps an example will help clarify this:
#pragma NOREGPARMS // Don't put arguments in registers long func_2 (long x) { long a, b, c, d; /*** 16 + 4 bytes = 20 bytes ***/ a = 1; b = 2; c = 3; d = 4; return (x + a + b + c + d); } long func_1 (long x) { long a, b, c; /*** 12 + 4 bytes = 16 bytes ***/ a = 11; b = 12; c = 13; return (x + a + b + c + func_2 (105)); } void main (void) { long a; /*** 4 bytes ***/ a = func_1 (100); while (1); }
SEGMENT DATA_GROUP +--> CALLED SEGMENT START LENGTH ---------------------------------------------- ?C_C51STARTUP ----- ----- +--> ?PR?MAIN?MAIN ?PR?MAIN?MAIN 0008H 0004H +--> ?PR?FUNC_1?MAIN ?PR?FUNC_1?MAIN 000CH 0010H +--> ?PR?FUNC_2?MAIN ?PR?FUNC_2?MAIN 001CH 0014H
SEGMENT DATA_GROUP +--> CALLED SEGMENT START LENGTH ---------------------------------------------- ?PR?MAIN?MAIN 0008H 0004H +--> ?PR?FUNC_1?MAIN
SEGMENT DATA_GROUP +--> CALLED SEGMENT START LENGTH ---------------------------------------------- ?PR?FUNC_1?MAIN 000CH 0010H +--> ?PR?FUNC_2?MAIN
SEGMENT DATA_GROUP +--> CALLED SEGMENT START LENGTH ---------------------------------------------- ?PR?FUNC_2?MAIN 001CH 0014H
SEGMENT DATA_GROUP +--> CALLED SEGMENT START LENGTH ---------------------------------------------- ?C_C51STARTUP ----- ----- ?PR?MAIN?MAIN 0008H 0004H ?PR?FUNC_1?MAIN 000CH 0010H ?PR?FUNC_2?MAIN 001CH 0014H
If only I could get the list you show. My results (with 6.01) is a long list of functions with ONLY the first having numbers associated with it. My perception is that these are the functions using the same space to store variables. HOWEVER, these functions use a varied number of variables and the length shown is for the one(s) using the most. What I show in the example some postings back is what I get.
OK - E-mail me the MAP file (jonw@keil.com). I'll take a look at it. However, I don't recall any problems with the 6.01 version of the tools generating this tree incorrectly. Jon