On Wed, Mar 17, 2010 at 10:29:37AM +0100, Maarten Brock wrote:
> Peter,
>
> >> Yes, stack-auto puts the sloc's on stack too. And you
> >> cannot move slocs to any other memory, because then SDCC
> >> would need sloc's to access those sloc's.
> >>
> > Does that then imply a severe limit on argument
Hi,
SDCC (not restricted to the pic ports) seems to be buggy with array
indices;
the problem is visible in the iCode as well.
struct s { int a; int b; char c; } arr[5];
char demo1(unsigned idx) { return arr[idx].c; }
char demo2(unsigned idx) { return arr[idx - 32].c; }
char demo3(unsigned ch
Thanks to Maarten and Borut's help I was able to get --model-huge code
working on my system.
I did run into one issue: if my code contains a _sdcc_external_startup
routine, the stack gets blown up on return.
As far as I can tell, what happens is this:
1. We jump to _sdcc_gsinit_startup
2. _sd
Maarten Brock wrote:
> Mark,
>
>
>> So, if I build a Linux compatible SDCC on Linux, can I use it to compile
>> the libraries and drop them into my windows environment?
> No, it should work ok.
>
This works perfectly.
>> What ./configure options do I need to use to enable the huge mode
>>
Hi, I am using following function to display data on LCD:
void table_to_nokialcd(unsigned char charsel)
{
unsigned char i;
for ( i = 0; i < 5; i++ )
{
nokia_write_data(FontLookup[charsel-32][i] << 1);
}
nokia_write_data(0x00);
}
but its not working properl
Peter,
>> Yes, stack-auto puts the sloc's on stack too. And you
>> cannot move slocs to any other memory, because then SDCC
>> would need sloc's to access those sloc's.
>>
> Does that then imply a severe limit on arguments to functions? Using
> both --model-large and --stack-auto makes the failing
>>
>>> The overflow in DSEG is all
>>> sloc variables and I don't know how to move those (thats what
>>> stack-auto
>>> is supposed to do I think?) out of the internal ram.
>>
>> Yes, stack-auto puts the sloc's on stack too. And you
>> cannot move slocs to any other memory, because then SDCC
>>
