Hi Kustaa,
Yes, this is sort of what I was looking for, but this did not completely answer the question.My array is not malloc'ated but is a global variable. I've not changed the default linker script and the compiler and linker seem to be happy.
This is strange: The attached source should not (and does not for me) link using the default linker script: The array largish[30] of 30 elements of an 11-byte struct consumes 330 byte of memory---no DATABANK is large enough. The linker yieldswarning: relocation of section "udata_larray_0" failed, relocating to a shared memory location error: linker script has no definition that matches the type of section "udata_larray_0"
If you use a modified linker script (see attachment), to compile/link the attached larray.c with --obanksel=9 given, you can observe two properties (see edited .lst excerpt): 1. Array accesses with variable index (largish[u].key = u) will work correctly (they use FSR0L/H with correct 16-bit arithmetics applied). Whenever the array index is truely unknown at compile time (and cannot be inferred by the compiler), you should be safe. 2. If the array index is a literal (largish[23].key = 0x44332211), the generated code will lack BANKSEL directives when accessing multi-byte entities that cross bank boundaries (.key is a 4 byte unsigned long starting at address 0x2FD (253 bytes after the first byte of largish) and runs on up to and including 0x300 (in the next bank). The banksel instructions for all but the LSB of .key are optimized away, leading to the code writing the MSB to 0x200 instead of 0x300. The same problem will occur even when accessing a different field/different index of the array (element)---all subsequent banksels to the symbol "largish" will be removed, due to the assumption that each symbol completely fits into a single bank.If you can *guarantee* that all array accesses happed with a variable index (e.g., by using accessor methods in a separate .c/.o file to prevent inlining), you *might* try to do this. I would reconsider my data structures and try to split the struct or the array to avoid this problem in the first place.
Alternatively (but still only true by chance --- which might change) you can leave out --obanksel and live with all the potentially required BANKSELs scattered throughout the code.
This sort of matches what was described in the thread you indicated but not quite. A word from the developer of PIC16 port would be appreciated.
Hope that clears things up a bit, Raphael
18f4550.lkr
Description: Binary data
larray.c
Description: Binary data
larray.lst
Description: Binary data
------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
