Feature Requests item #3513994, was opened at 2012-04-01 14:34
Message generated for change (Comment added) made by achdawai
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3513994&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: pic16 target
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: achdawai (achdawai)
Assigned to: Nobody/Anonymous (nobody)
Summary: named code sections
Initial Comment:
hi
for the moment all PIC16 code sections are named according to the file and function, and #pragma codeseg has no effect.
The only way to change the code's position is using a command line option that defines the beginning of the code *segment*.
For a boot/os/app software design, a way to assign a specific section to any function is desired.
gplink already supports that.
the only required bit is a working #pragma codeseg <section> that will define the current section name instead of a S_file__func template
Is this naming required for anything?
Is this request doable?
thanks for any info.
----------------------------------------------------------------------
>Comment By: achdawai (achdawai)
Date: 2012-05-02 09:34
Message:
BTW, after an as-deep-as-i-could look in gpasm code, supporting mixed
sections is far from trivial ;)
one would have to remember the "org" for each section, which is not done at
the moment.
----------------------------------------------------------------------
Comment By: achdawai (achdawai)
Date: 2012-05-02 09:31
Message:
Any help about how to do that would be greatly appreciated, because I don't
know the sdcc codebase enough for this.
Would you like to review my patch implementing the "text" pragma? It's
quite trivial but that could help.
Is any discussion about the name of this pragma relevant? I would have
called it "code" but this pragma is already defined (and useless for that
role).
Assigning a *function* to an address (like is done by #pragma code) could
be managed by a named section at the proper place (via a linker script),
but this change could break existing code relying on this feature. Any
thought?
regards
----------------------------------------------------------------------
Comment By: Borut Ražem (borutr)
Date: 2012-05-02 09:02
Message:
> sections names must be unique within each file, just because old mplab
documentation wrote that.
This should not be a problem for sdcc: it should just collect all functions
/ variables belonging to the same section and group them together in the
generated asm so that the section is defined only once.
Borut
----------------------------------------------------------------------
Comment By: achdawai (achdawai)
Date: 2012-04-03 02:10
Message:
I'm now bumping into gputils feature request 951216
No news since 2007-11-24 08:58:21 PST !
I can't believe it!
sections names must be unique within each file, just because old mplab
documentation wrote that.
There is absolutely no requirement on that, but nobody wants to "break
compatibility".
I will investigate that.
----------------------------------------------------------------------
Comment By: achdawai (achdawai)
Date: 2012-04-02 17:42
Message:
I just implemented a simpler idea, see attached patch against svn 7529.
now, from sdcc side, it works.
However I'm getting into gpasm issues, see the attached test case, compiled
with:
sdcc -c --use-non-free -mpic16 -p18F2620 bootmain.c -o bootmain.o
main.c:444 placing udata symbol _var at section boot (0x924fc18)
main.c:444 placing text symbol _start at section boot (0x9250c60)
main.c:444 placing text symbol _appmain at section app (0x925cff8)
main.c:444 placing text symbol _appsuite at section app (0x925cff8)
for function _appsuite a section was found : app
section app found in the list of text sections
for function _appmain a section was found : app
section app found in the list of text sections
for function _start a section was found : boot
section boot found in the list of text sections
bootmain.asm:223:Error[154] Each object file section must be contiguous.
bootmain.asm:223:Error[116] Value of symbol "_appmain" differs on second
pass
pass 1=0, pass 2=16
bootmain.asm:247:Error[154] Each object file section must be contiguous.
bootmain.asm:247:Error[116] Value of symbol "_start" differs on second
pass
pass 1=0, pass 2=16
Please see the attached bootmain.lst and bootmain.asm .
In the asm file, everything is OK.
However gpasm does not like to see two functions in the same section!
The first pass assembles each function at address zero, however the second
pass concatenates the similar sections and signals an address change!
Any ideas?
----------------------------------------------------------------------
Comment By: achdawai (achdawai)
Date: 2012-04-02 17:34
Message:
a better idea was implemented, see attached patch against svn
----------------------------------------------------------------------
Comment By: achdawai (achdawai)
Date: 2012-04-02 15:26
Message:
OK, I tried to get a working sdcc source tree under mingw but I can't get
it to compile! I have downloaded boost (96MB!) , I understand I don't have
to compile anything to use graphs, I have it exported in CXXFLAGS and
CPPFLAGS, but it does not work, I get various compilations errors.
So let it be. I'll do it in linux.
At the moment, I:
-managed to understand how the asm file is generated via pcode elements. I
added a "char *section" field in the pcode structure for functions, added a
parameter to pic16_newpCodeFunction and got it compiled. For the moment all
calls use NULL here so pcode.c generates the normal function prolog. If
this field is not null, a simpler prolog is generated using the passed
section name instead of S_%s__%s.
-managed to add a #pragma text [sym] [section] that is, for the moment
managed the exact same way as #pragma udata.
What I need to understand now is how #pragma data is propagated to pcodes.
Any help is welcome, especially from the main developers.
----------------------------------------------------------------------
Comment By: achdawai (achdawai)
Date: 2012-04-02 03:01
Message:
I can get the needed effect for RAM variables, e.g.
#pragma udata boot timer_msw
ushort timer_msw;
generates:
boot udata
_timer_msw res 2
I will try to compile something similar for code sections.
#pragma code <section> <function>
but for the moment, pragma code works like a ".org" :
#pragma code <function> <address>
that's not very coherent.
#pragma codeseg seems to have another meaning.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350599&aid=3513994&group_id=599
|