[sdcc-devel] [ sdcc-Bugs-3125533 ] Biger code than I expected ( PIC14 )

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

Bugs item #3125533, was opened at 2010-12-02 15:11
Message generated for change (Settings changed) made by maartenbrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3125533&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: pic14 target
>Group: non bugs
>Status: Closed
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: Gál Zsolt (galzsolt)
>Assigned to: Maarten Brock (maartenbrock)
Summary: Biger code than I expected ( PIC14 ) 

Initial Comment:
I realised that sdcc put some additional code into the assembly list which have no function. The test file is attached to this report.

What I wanted to do, is transfer a high byte of a signed integer value into a function which is expected an unsigned char variable. I got this code ( removing the debug messages ):

	BANKSEL	_b
	MOVF	(_b + 1),W
	BANKSEL	r0x1002
	MOVWF	r0x1002
	CLRF	r0x1003
	BTFSC	r0x1002,7
	DECF	r0x1003,F
	MOVF	r0x1002,W
	CALL	_function

It looks that value B moving into an r0x1002 file then a condition which doesn't change this value and then this value goes into the working register. So it has no any function.

I think the correct result would be this:

	BANKSEL	_b
	MOVF	(_b + 1),W
	CALL	_function

SDCC : pic14 3.0.1 #6070 (Nov 29 2010) (Linux)


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

>Comment By: Maarten Brock (maartenbrock)
Date: 2010-12-02 22:02

Message:
As Steven already explained this is no bug.
There is no guarantee at all how efficient the generated code will be, if
the result is correct it is no bug. And for the pic14 port which isn't even
stable yet, efficiency is very low priority.

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

Comment By: Steven Borley (sjborley)
Date: 2010-12-02 20:38

Message:
Gál, sorry, please ignore my last comment, you did attach an example. My
mistake.
My other comments still stand though.

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

Comment By: Steven Borley (sjborley)
Date: 2010-12-02 20:35

Message:
I don't see this as a bug. The extra code is due to the sign extension.

I assume your c-code looks something like this...

volatile signed short bob;

void main(void)
{
	bob = 0xAA55;
	
	function(bob>>8);
}

The signed short is first sifted right with sign extension, then subject
to an implicit cast to an unsigned char in the function call.  

However, the following avoids this sign extension and gives you something
closer to what your were expecting

union {
	signed short value;
	unsigned char byte[2];
} bob;

void main(void)
{
	bob.value = 0xAA55;
	
	function(bob.byte[1]);
}

gives...

MOVWF   (_bob + 1)
MOVWF   r0x1002
CALL    _function

If you still think this is a bug please post you c-code so we can. I
suggest a complete example like the one I've attached 

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

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