Hi Raphael,
thanks for a very thorough treatment of the topic!
Just what I was looking for.
And yes, you are correct the code does not link with the standard
linker script if I make my array larger than 256, my mistake.
All in all, I think it is safer to conserve some memory and
keep the array all on one page.
Thank you once more.
br Kusti
________________________________________
From: Raphael Neider [rnei...@web.de]
Sent: Thursday, February 26, 2009 12:25 AM
To: sdcc-user@lists.sourceforge.net
Subject: Re: [Sdcc-user] Larger than 256 byte arrays in PIC16
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 yields
warning: 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
------------------------------------------------------------------------------
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
