Hi Maarten,
Quick reply, as usual. Thanks
I just had a look at aslink 5 docs. There appears to be a B designator, used to
combine areas into seperate BANK collections. B lines include a size spec and
as a result aslink can detect overflows and throw errors (handy!). I can't see
anything explicit about auto allocations.
As a side note, is banking currently broken in more ways than what discussed in
bug #3420365? I follow the list and I'm watching the bug so if there is any way
I can help, shout.
Regards
geo
----- Original Message -----
From: Maarten Brock
To: sdcc-user@lists.sourceforge.net
Sent: Thursday, October 27, 2011 12:56 PM
Subject: Re: [Sdcc-user] Automatic Bank Allocation for mcs51 model-huge
Hello George,
Your idea is a logical one. When I implemented banking for the mcs51 I
knew this was next. But my implementation is of course totally different
from what the author of ASXXXX had done. And since we are now allowed to
merge with the current ASXXXX again, my implementation will probably go
away in the future. One result of merging our old aslink with a more
current one is that banking is currently broken. It is my intention to
first try to fix banking before the upcoming release (I hope to find the
time). Then after that more of aslink 5 will go into sdlink. Maybe what
you propose is already in aslink 5 (I haven't checked) and otherwise it
would a good extension.
Maarten
> Hello all,
>
> I've been toying with this idea for a while and I found time and played
> around a bit the last couple of days. The principle here is that with
> model huge, most source files can be allocated to any code segment. The
> reasoning is that with a 'large' project, manual bank assignment requires
> a fair bit of maintenance and, for the not-so-experienced user, can lead
> to bank overflows and 'why on earth is my device crashing all the time?'
> moments.
>
> What I've done with contiki for cc2430 is, I've written a script which
> gets invoked by the build system. Things work like this:
>
> - For sources that need to be in a certain segment, we specify so with a
> pragma or with --codeseg (e.g. sources with ISRs).
> - Compile everything and link. Free-to-reallocate modules are initially
> assigned to a dummy segment
> - The script reads the mem, map and rel files for information on code
> sizes
> - We calculate the remaining free space of each bank by subtracting
> pre-allocated code size from their capacity. Pre-allocated in this context
> also means CONST, startup code, huge libraries etc
> - We then allocate the remaining segments to banks automatically. This
> problem is a very simple bin-packing variant, which can be solved with a
> very fast heuristic (first-fit, decreasing is what I've done but there are
> probably better approaches)
> - Having reached a feasible target assignment, we edit each modules's .rel
> in-place and then re-link.
>
> So users are free to manually specify as many assignments as they like.
>
> I built a 6lowpan border router for cc243x (Sensinode n601 NanoRouters)
> with this technique. The output at the end of this message shows what I'm
> doing. As can be seen, the resulting build is rather crowded but segments
> are getting filled up quite nicely. The image has so far been working as
> intended
>
> Having to rely on Make, a script and two linker invocations, the current
> approach is a bit ugly. I am now planning to try and dig through the SDCC
> sources, see if I can make this built-in. My initial thoughts about this:
>
> - It would need a new linker argument in order to specify the capacity of
> each bank. Something like -Wl-xyzBANK1=0x8000. Probably also a new linker
> argument to turn the feature on/off
> - A way of specifying that a source is free to move around. This could be
> as simple as a reserved codeseg keyword, e.g. --codeseg __ANY or it could
> be a new compiler argument. In the rel file, the A __ANY line would
> probably be enough (?)
>
> Any form of feedback would be great. Do you think this is
> reasonable/feasible/remotely interesting? Any caveats I should watch out
> for?
>
> Best Regards and as ever, thank you for your time and for all the efforts
> maintaining SDCC
> George
>
> First Link
> ==============sdcc --model-huge --stack-auto -DSDCC_CC2430 --out-fmt-ihx
> --xram-loc 0xE000 --xram-size 0x1F00 --code-loc 0x00000 --code-size
> 0x20000 -Wl-bBANK1=0x018000 -Wl-r -o border-router.ihx
> obj_sensinode/contiki-sensinode-main.rel
> obj_sensinode/border-router.app.rel -llibsdcc.lib -lcontiki-sensinode.lib
> ...
>
> Bank Allocation
> ==============python ../../../cpu/cc2430/bank-alloc.py border-router
> obj_sensinode/segment.rules
> Total Size = 114797 bytes (100987 bankable, 2029 user-allocated, 11781
> const+libs)
> Preallocations: HOME=13810, BANK1=0, BANK2=0, BANK3=0
> Bin-Packing results (target allocation):
> Segment - max - alloc
> HOME 32768 18564
> BANK1 32768 32758
> BANK2 32768 32762
> BANK3 30720 30713
>
> Final Link
> ==============sdcc --model-huge --stack-auto -DSDCC_CC2430 --out-fmt-ihx
> --xram-loc 0xE000 --xram-size 0x1F00 --code-loc 0x00000 --code-size
> 0x20000 -Wl-bBANK1=0x018000 -Wl-r -Wl-bBANK2=0x028000 -Wl-bBANK3=0x038000
> -o border-router.ihx obj_sensinode/contiki-sensinode-main.rel
> obj_sensinode/border-router.app.rel -llibsdcc.lib -lcontiki-sensinode.lib
> ...
>
> Report
> ==============Code footprint:
> Area Addr Size Decimal
> ---------------------------------- -------- -------- --------
> HOME,CSEG,CONST,XINIT,GS* 00000000 00004884 = 18564.
> bytes (REL,CON,CODE)
> BANK1 00018000 00007FF6 = 32758.
> bytes (REL,CON,CODE)
> BANK2 00028000 00007FFA = 32762.
> bytes (REL,CON,CODE)
> BANK3 00038000 000077F9 = 30713.
> bytes (REL,CON,CODE)
> Other memory:
> Name Start End Size Max
> ---------------- -------- -------- -------- --------
> PAGED EXT. RAM 0 256
> EXTERNAL RAM 0xe000 0xf664 5733 7936
> ROM/EPROM/FLASH 0x0000 0x3f7f8 114797 131072
>
------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
>
http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
