Anomily with XC8

[bxdobs]

W7pro 64b using MPLAB v5.3 with XC8 v2.10

Project using a PIC12F629

The following C code, specifically lCase(), isn't being compiled properly by XC8:

Code: [Select]

char uCase(char cC)
{
 return (cC & ccUCMask); // 0xDF
}
char lCase(char cC)
{
 return (cC | ccLCMask); // 0x20
}

results in:

Code: [Select]

02D8 1283 BCF 0x03,5
02D9 00B4 MOVWF 0x34,F
02DA 0834 MOVF 0x34,W
02DB 39DF ANDLW 0xDF
02DC 0008 RETURN  


Code: [Select]

02DD       0008        RETURN

This was expected to provide:

Code: [Select]

02D8 1283 BCF 0x03,5
02D9 00B4 MOVWF 0x34,F
02DA 0834 MOVF 0x34,W
02DB 39DF ANDLW 0xDF
02DC 0008 RETURN  


Code: [Select]

02DD 1283 BCF 0x03,5
02DE 00B4 MOVWF 0x34,F
02DF 0834 MOVF 0x34,W
02C0 39DF IORLW 0x20
02C1 0008 RETURN  

2 attempts at forcing the compiler to provide a working solution by explicitly using a local variable

This one fails

Code: [Select]

char lCase(char cC)
{
 char cX = cC;
 return (cX | ccLCMask);
}


This C Code works but returns way too much machine code

Code: [Select]

char lCase(char cC)
{
 char cX = cC;
 cX = cX | ccLCMask;
 return (cX);
}


Code: [Select]

02C1 1283 BCF 0x03,5
02C2 00B5 MOVWF 0x35,F
02C3 0835 MOVF 0x35,W
02C4 00B4 MOVWF 0x34,F
02C5 0834 MOVF 0x34,W
02C6 00B6 MOVWF 0x36,F
02C7 0836 MOVF 0x36,W
02C8 3820 IORLW 0x20
02C9 00B4 MOVWF 0x34,F
02CA 0834 MOVF 0x34,W
02CB 00B6 MOVWF 0x36,F
02CC 0008 RETURN  

At a high level, it would appear the "|" isn't being compiled properly if included within the return() statement
I could forcibly use asm("IORLW 0x20"); but wasn't expecting to 2nd guess the compiler.

Thoughts?

[bxdobs]

So I have resolved this issue using Predefined Macros ... rather than try and understand the Compiler failure

Code: [Select]

#define uCase(x) (x = x & ccUCMask)
#define lCase(x)  (x = x | ccLCMask)

I have confirmed my code is now compiling with what is expected ... PLUS ... not wasting time and space with Calls/Returns

[Shonky]

Works for me here with xc8 2.41

Code: [Select]

_lCase:
;incstack = 0
callstack 7
; Regs used in _lCase: [wreg+status,2]
;lCase@cC stored from wreg
bcf status, 5 ;RP0=0, select bank0
movwf (lCase@cC)
line 12

l623:
;xc8test.c: 10: char lCase(char cC);xc8test.c: 11: {;xc8test.c: 12:  return (cC | (0x20));
movf (lCase@cC),w
iorlw 020h
line 13

l6:
return
I'm not a fan of this though:

Code: [Select]

#define uCase(x) (x = x & ccUCMask)
#define lCase(x) (x = x | ccLCMask)
Making a define that looks like a function but changes parameters is a no no in my mind. Also you should always parenthesise macro parameters IMO even if you're sure you won't ever cause a problem.

Code: [Select]

#define uCase(x) ((x) & ccUCMask)
#define lCase(x) ((x) | ccLCMask)

x = lCase(x);
x = uCase(x);


[DavidAlfa]

What optimization level? Remember O2 is free.
Os will produce the optimized result you would expect with manual assembly, but it's no longer free.

Also what values are you feeding to the function?
The compiler migh be smart enough to detect the variable needs zero processing, for example if you're or'ing 0xF0 with 0x20.

You could skip this optimization by forcing the variable to be treated as volatile, then check the output asm.

Code: [Select]

char lCase(char cC)
{
 return ((volatile char) cC | ccLCMask); // 0x20
}


[Shonky]

-Os and -O3 both produce the correct (and the same) code in 2.41

[JPortici]

What optimization level? Remember O2 is free.
Os will produce the optimized result you would expect with manual assembly, but it's no longer free.

-Os was never free

i wonder if the "problem" is integer promotion that could probably be solved by casting the result or the arguments. I don't have XC8 on this machine to test. Doesn't the compiler nag you about fitting a short into a char?

Anyway a better way to look at the disassembly is to post the disassembly listing file (build for debug and go to window->debug->output->disassembly listing file) because there is zero context here

[DavidAlfa]

-Os was never free

I know, I know.
I mean it's no longer free (After you set Os), in the context that O2 is.

Yeah using chars seems wrong, I only use them for char..acters!
But I guess it works anyways if using hex literals.