[sdcc-devel] [ sdcc-Feature Requests-1584152 ] register allocated variables in omf file

[SourceForge.net <no...@so...>]

Feature Requests item #1584152, was opened at 2006-10-25 06:22
Message generated for change (Comment added) made by maartenbrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1584152&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: mcs51(8051) target
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Robert (regsoft)
>Assigned to: Maarten Brock (maartenbrock)
Summary: register allocated variables in omf file

Initial Comment:
SDCC is producing a .map file and I can use that to
shuffle through the ram window and see the values but
the system will not load them in to the Symbol View tab
or watch windows in my more involved app. I see that
the problem in blinkey requiring the loading of values
in to the watch window from the Symbol View tab is CaSe
SeNsItIvItY! In both cases I am using --debug and the
--model-medium in tool integration.
=========
Attached you will find SDCCTest.zip you should be able
to just load the .wsp if you place the SDCCTest dir in
the root of C:\. Please let me know if your system
allows you to view "busy_loop_count" or "irupt_rate"
both the all caps version out of the sybols tabe and
the lower case version out of the code always show 00
in the watch window on my system.

And I got this reply from SiLabs starting at Hi Robert,
BTW is there a way to specify in the "no extion output
file" that a vairable is in a registor? That shouild be
idata, no?

Hi Robert,
 
    I was able to reproduce the problem, and I can see
what is happening.  The SDCC compiler is optimizing the
two variables you are trying to watch into register
locations (R2/R3 and R4/R5, specifically).  For some
reason when it does this, both of the symbols in the
symbol table are pointing to location 0xFF in DATA
space, which is incorrect.  I have entered a report in
our tracking software so that the people writing the
IDE software can investigate this further.  However, it
is still unclear if this is something in the debug
output of the SDCC compiler or if it is our IDE's
interpretation of their debug output that is causing
the issue.  I have identified a couple workarounds you
could use in the meantime, while we investigate this:
 
1) Declare the variables as "static".  This will
prevent the compiler from optimizing them into register
space.  The drawback here is that the code will not be
quite as fast or compact as it was before.  This can be
used as a temporary solution for individual variables
you want to watch.
 
2) Identify the locations of the values manually from
the compiler's list file output (.lst).  They look like
this in my list file:
 
1286
;------------------------------------------------------------
1287 ;Allocation info for local variables in function
'main'
1288
;------------------------------------------------------------
1289 ;busy_loop_count           Allocated to registers
r2 r3
1290 ;irupt_rate                Allocated to registers
r4 r5
1291
;------------------------------------------------------------
 
Then, use this information to view these variables in
the Register window (View->Debug Windows->Registers),
or view them in the corresponding RAM locations.
 
3) Use a variable of a different name defined as static
to copy the contents of the variables at the point(s)
where you want to watch them in code, and watch the new
variable instead.  Again, this messes with the code
generated by the compiler, so it is good only as a
temporary solution.
 
I hope this helps.  I will let you know if I get more
information about the issue, and whether it is
something we can change in the IDE or something that
needs to change in SDCC.
 
Regards,
 
-Bill Durbin


----------------------------------------------------------------------

>Comment By: Maarten Brock (maartenbrock)
Date: 2011-03-28 11:40

Message:
SDCC 3.0.2 no longer outputs invalid entries with 0x00FF as address. For a
variable allocated to adjacent and ascending registers it now does output
an entry with the address of the registers. Variables with non-adjacent or
non-ascending registers are not output.

----------------------------------------------------------------------

Comment By: Maarten Brock (maartenbrock)
Date: 2006-10-25 07:44

Message:
Logged In: YES 
user_id=888171

Hello Robert,

Now it finally sinks in. You have trouble with local variables which are
allocated to registers. These variables 
are not allocated to any address so they cannot be put in the OMF. The
linker uses 0xFF as default.
The registers actually do have an address but I would call it a feature
request to put those addresses in the OMF 
(if that is at all possible for int, long and float).

Maarten

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=1584152&group_id=599