Endless frustrating fight against XC8

olifri
I misunderstand some basic concepts of ... the C language

void* state1(void);
void* state2(void);

void* state1(void){
    return state2;
}

void* state2(void){
    return state1;
}

The compiler surely warned you about the type mismatches in your two example functions.
You first tell the compiler that each function will return a value of type pointer-to-void, but then you attempt to return a value of type pointer-to-(function-returning-pointer-to-void).
 
What you want to do here can't strictly be done in C.
See http://c-faq.com/decl/recurfuncp.html
 
If you can avoid pointers-to-functions in PIC code you will be much happier. The 8-bit PICs all have very function-pointer-unfriendly architectures.

Hi,
 
MCC use function pointers quite regularly, and it work there.
However, it do not pass function pointers around as function retirn values.
 
In I2C  driver code for Master mode, there is a state machine using a array of function pointers,
passing the index into the array of function pointers, as function return value.
 
You may look at how it is done there.
 
    Mysil

nigelwright7558
 I havent noticed it too much with xc8 but in xc32 it starts removing artificial delay loops !

XC8 will remove "do nothing" loops if the count variable is not "volatile".
That is why they supply delay macros that will never be optimised away.
 

I haven't checked but can you prevent a function being optimised away by dummy calling it after the while loop, or does the compiler recognise that the dummy calls aren't reachable?
 

mark.pappin
 
The compiler surely warned you about the type mismatches in your two example functions.
You first tell the compiler that each function will return a value of type pointer-to-void, but then you attempt to return a value of type pointer-to-(function-returning-pointer-to-void).
 
What you want to do here can't strictly be done in C.
See http://c-faq.com/decl/recurfuncp.html
 
If you can avoid pointers-to-functions in PIC code you will be much happier. The 8-bit PICs all have very function-pointer-unfriendly architectures.

Sorry for responding so late, I had to sort out a few things first.
First of all, thank you for everybody's response.
Although, I could not see the "truth" in the quoted answer from mark.pappin in the first place, it turned out to be the solution to all my troubles and pain. THANK YOU, Mark;-)
I rewrote my code and got rid of the passing around function pointers and my code is running flawlessly ever since.
 
THANK YOU!
So, that was a pretty hard lesson to learn...but
 
a) As far as I can remember the compiler never issued any warnings regarding type mismatch!
 
b) Matter of fact, the function pointer stuff itself was working...but obviously had any number of nasty side effects and this is what I call bad behaviour!
 
c) I do not agree with your argument, that I should avoid function pointers due to lack of support by the architecture. I can sure do function pointer in assembly language, so the architecture is ready for it. And then I expect the compiler to implement that stuff in a proper way or just to refuse to compile if "he" is unsure.
 
d) My code from some two years ago had almost exactly the same architecture, also utilizing the function pointer design pattern...and I never had any trouble with that code and XC8 1.44. So, I definetely blame the compiler!
 

NKurzman
XC8 Version 1.41 (Still Available) is a C90 Compiler
XC8 V2.31 will Default to C99.  This is why you can not build your Original Code.
You can Get an Use the Original Compiler.
Or you can Use V2.31  by selecting C90 Mode.
 
And No The Compiler being Buggy is not the Issue here.
The Compiler is tossing code because it is not being used.  If it is wrong, it is because you have issues in your code.  Or you are being very clever with pointers.  It is an Optimizing Compiler.  That is what it does.  Why fight with it?

Yes, you are right, from the compiler's point of view, my example is totally useless. But isn't it up to the designer to decide if he wants to write "useless" code?
In my very example I couldn't even provide you a example of my bug, which I wanted to show to you...because the compiler didn't let me build up an example that comes to the point...because it spoils all my attempts from the very beginning, influencing and bend the code to what "he" believes is ...kind of "useful":-( F##k off!
 
I have searched the web for the one golden option that turns off optimization globally and prevent the compiler from making any assumptions of "use".
Although, my project settings clearly shows "XC8 Compiler -> Optimizations->Optimization level: 0" DO NOT OPTIMIZE, it optimizes...That's what I call buggy behaviour, isn't it?
 
Declaring variables as "volatile", calling functions after the while(1) loop, declaring assembly symbols...just to desperately prevent the compiler from screw up your code...THAT is what produces useless, hard to read and ugly code!
 
Greetings
Oli
 
 

olifri
Although, my project settings clearly shows "XC8 Compiler -> Optimizations->Optimization level: 0" DO NOT OPTIMIZE, it optimizes...That's what I call buggy behaviour, isn't it?

I fell for that too. :(  It still optimizes.  It can even change your assembly code!
 

Declaring variables as "volatile", calling functions after the while(1) loop, declaring assembly symbols...just to desperately prevent the compiler from screw up your code...THAT is what produces useless, hard to read and ugly code!

Yeah!
 

olifri
Although, I could not see the "truth" in the quoted answer from mark.pappin in the first place, it turned out to be the solution to all my troubles and pain. THANK YOU, Mark;-)

You're welcome.
 

a) As far as I can remember the compiler never issued any warnings regarding type mismatch!

Maybe it's not as smart as I thought it was.
 

c) I do not agree with your argument, that I should avoid function pointers due to lack of support by the architecture.

I didn't say "lack of support"; I said "unfriendly". Argue further when you've written a C compiler for this architecture.
 
 

isn't it up to the designer to decide if he wants to write "useless" code?

Sure, until he hands it to an optimizing compiler for a resource-constrained architecture.
 
 
In everything, just because you Can, doesn't mean you Should.