[sdcc-devel] [ sdcc-Bugs-1500467 ] Missing banksel for function parameter

[SourceForge.net <no...@so...>]

Bugs item #1500467, was opened at 2006-06-04 13:13
Message generated for change (Settings changed) made by tecodev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1500467&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: non bugs
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: kein0r (kein0r)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Missing banksel for function parameter

Initial Comment:
Since the sdcc-users mailinglist seems to be not
working i post this bug again here.

Found a small but really annoying bug in the pic16 port
of the sdcc. sdcc is compiled from svn.

The Problem: All Register in the pic16 are 12Bits.
Writing to these registers must either be via the W
register and a "bank select" first or with the movff
command.

When i write the following function (this function
doesn't make any sense, its just to demonstrate the
problem):

void func1 (char a, unsigned int b, char c, unsigned int d)
{
        SPBRG = a;
        SPBRG = (char) b;
        INTCON = c;
        INTCON = (char) d;
}

The values a, and c are written correct to the register
because sdcc generates code like:

movff r0x00, SPBRG
and
movff r0x02, INTCON

but for the two int values sdcc, generates:

movf r0x01, W
movwf SPBRG

without any bankselect first. glink then generates the
following assembler code out of it:

movwf 0xaf, 0

The register SPBRG is *not* 0xaf but 0xfaf but since
movwf can only handle addresses up to 0xff there must
be either a bank select before or the movff command
must be used.

My problem is that i want to use a few external
functions which are defined like the one above.




----------------------------------------------------------------------

Comment By: kein0r (kein0r)
Date: 2006-06-21 08:47

Message:
Logged In: YES 
user_id=1212013

that did it. Thx all for the help and sorry for wasting your
time.

----------------------------------------------------------------------

Comment By: kein0r (kein0r)
Date: 2006-06-20 19:25

Message:
Logged In: YES 
user_id=1212013

yes i have set ENHCPU_ON_4L, didnt thought that this could
be the prob. Ill test this tomorrow as soon as im back in
the lab

----------------------------------------------------------------------

Comment By: Jim Paris (jimatjtan)
Date: 2006-06-20 18:04

Message:
Logged In: YES 
user_id=175928

The behavior of the access bank changes if the extended
instruction set is enabled.  Maybe you have the XINST config
bit set incorrectly?


----------------------------------------------------------------------

Comment By: kein0r (kein0r)
Date: 2006-06-20 17:35

Message:
Logged In: YES 
user_id=1212013

First thank allot for your effort to solve this issue.

I dont think a BANKSEL is the solution/problem nmore. This
was just my first guess when i found the error.

Its a pic18f2550 (rev 2) with the normal max232 circuit
conencted to the pc.
The Problem was that the open_serial function from the sdcc
library didnt worked for me so i tried to find the error
which showed that the "unsigned int spbrg" value was not
correctly written to the SPBRG register.

Again: The Problem does no occur when i use char spbrg since
then sdcc directly uses movff to copy r0x00 to SPBRG reg.

Wihout the __asm block the code compiles but the value
written to SPBRG is wrong and minicom only shows garbage.
Whit the __asm block everythin works fine.
I dont think that this is a stack problem since the movff
r0x00,SPBRG works. So the value on the stack und thus in
r0x00 should be correct.

I just found out that if i add an __asm block with
MOVLW	0x33
MOVWF	_SPBRG
instead of the other __asm block where 0x33 is the value i
want to write to spbrg the programm also works. This makes
the problem even more weird.

I tried the following stack option:
- no stack pragma (only works since 2.5.6 afaik)
- #pragma stack 0x200 64
- extern stack;
  extern stack_end;

all with the same result.
BTW: With what programm did you simualte the code?



----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2006-06-20 16:23

Message:
Logged In: YES 
user_id=1115835

I still do not understand *why* this fails: Did I get it
right that you have some code A that compiles but does not
show the expected results when executed in hardware? Then
you have code B that compiles fine and executes as expected
in hardware? And the only difference between A and B is the
"__asm movff r0x00, _SPBRG __endasm;" statement? That is
mightily queer...

Could you pass along some information about the device you
are actually using, so that I can look up the "device
dependent limit"? (See previous posting, maybe its at 0xb0
for your PIC and our device description is just wrong)?

For obvious reasons, I am pretty much unwilling to add
BANKSELs before each and every register/SFR access, and I
currently see no way to discern your (broken) example from
other (but working) examples...

BTW: Simulating your code using a pic18f1220 shows that the
code "should be ok" (tm); there's something fishy... Where
is your stack located? How large is it? (The 1220 has severe
memory limitations, when trying to simulate it I just
wondered whether this might be a problem...)

Still confused,
Raphael Neider


----------------------------------------------------------------------

Comment By: kein0r (kein0r)
Date: 2006-06-20 15:41

Message:
Logged In: YES 
user_id=1212013

Can you confirm this still exists in 2.5.6?

----------------------------------------------------------------------

Comment By: kein0r (kein0r)
Date: 2006-06-20 15:41

Message:
Logged In: YES 
user_id=1212013

Sorry had much work and it took me quite some time to figure
out exactly where the error lies.
Its either in the code generated by sdcc or a bug in gpasm.

For testing i defined a function like:

void set_spbrg (unsigned int spbrg) {
SPBRG = spbrg; // 48MHz => 57.600 baud (BRGH = 1)
__asm
MOVFF r0x00, _SPBRG
__endasm;
}

Without the __asm block the program doesnt work, cause sdcc
generates
MOVF	r0x00, W
MOVWF	_SPBRG

With the __asm block the programm works. 

The Problem is that unsinged int is used in many picv16 lib
i.e. in serial_open, which wont work with this bug.

Version
SDCC : avr/pic16 2.5.6 #4243 (Jun 20 2006) (UNIX)
gpasm-0.13.3 beta
gplink-0.13.3 alpha


----------------------------------------------------------------------

Comment By: Raphael Neider (tecodev)
Date: 2006-06-06 07:34

Message:
Logged In: YES 
user_id=1115835

If I am not mistaken, SDCC is right here.
Reasoning:
The PICs sport an access bank, which redirects accesses to
registers 0x00..0x7F (upper bound device dependent) to bank
0 and accesses to 0x80..0xff (lower bound device dependent)
to bank 0xf (thats 0xf80..0xfff).

>From your code snippet I gather that the "movwf 0xaf, 0"
uses the access bank feature (trailing ", 0") and thus needs
not select bank 15 manually.
The same holds for the r0xXX, as they are also allocated
into the access bank (bank 0, hopefully we never reach the
device dependent limit ;-)).

Regards,
Raphael

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1500467&group_id=599