Function Pointers really need some attention...

[Sy]

I have a structure with a function pointer. If I assign the function pointer to a function in the same module everything is ok.

I've been cleaning up the code today and have created an initialisation helper function, the function is now passed to the helper as a parameter then assigned to the structure instance.

The helper is in another module, but the prototype for the helper is defined in a header and the header included in the main module, however when I compile I get:

"Reentrancy is not allowed: function '.....' called from two threads."

This is just not true and is very frustrating, I've encountered this before. What can I do, in my opinion this is a bug in the compiler.

[Sy]

Bump....please someone from MikroElektronika address this issue.

"Reentrancy" is not an error or a bug it is a legitimate coding technique.

[janko.kaljevic]

Hello,

Please can you post here an example for this behavior.

Reentrancy error is generated due to PIC 16F and 18F hardware limitations.
Functions reentrancy is allowed if the function has no parameters and local variables.

If your project requires reentrancy, you should consider using dsPIC controller.

Best regards.

[Sy]

Can I plug a dsPic into the easyPic v7 ?

[p.erasmus]

Sy
You can not use EasyPic7 for development work on dsPIC!

[Sy]

Typical!

I cannot see why MikroElektronika are saying:

Reentrancy error is generated due to PIC 16F and 18F hardware limitations.

Reentrancy is no different from calling any other function. Ok if your silly and allow so many levels of reentrancy that you overflow the stack or the memory that is allocated for the stack then thats your problem as a coder, but you can just as easily do the same by calling different functions from within each other, sooner or later you are going to run out of space.

The PIC 16F and 18F both support calling functions with parameters and local variables, they handle this and seem to be able to call functions from within functions, so I can only assume that there is a stack of sorts.

So why can't you permit reentrancy ?

Please explain.

[zristic]

Typical!

You cant put truck gearbox into a motorcycle... well, at least not without modifying the motorcycle.

Re-entrancy: PIC16 and PIC18 have problematic solution for stack and stack pointer. From that reason, we simulate the stack in the following way: at first, all variables are taken as global variables. They are all assigned a unique RAM address. Then, we run analysis of inter procedural calls to determine if routine A calls routine B. If this is not the case, then routine A and routine B share the local variables and parameters in the sense that those variables are put at the same addresses. That is the simplified explanation of the linking process.

Secondly, you want to use one function from both main and interrupt. This means that at any point interrupt can take over the main thread and to start executing. If you were running a procedure at that moment, then its context (locals and vars) is not saved on the stack (push instruction is missing on P16 and on P18 is practically useless). So the interrupt may run the problematic procedure again, overwriting its parameters and locals, then upon the return to the main thread these values are corrupted. The same stands for recursions.

On PIC24/30/32, AVR too, there is a real hardware stack inside the MCU, so the compiler can rely on PUSH and POP instructions freely, so you are able to make renetrancies as much as you wish.

If you use pointers to functions, then the compiler is never sure if you are going to call one function from another via pointers and that is another problem.

I hope I explained a bit. It is much more complex than what I wrote, but I tried to keep it simple for the sake of easier understanding.

One more thing, PC programmers have problems to switch to MCU programming. In my opinion, those are two different worlds, but the switch is possible, with a bit of patience and lot of hard work.

[Sy]

Thank you for the reply.

The approach you have taken isn't good, why didn't you create your own stack in RAM? And just push and pop directly to the allocated area of RAM for stack space?

The approach you have taken changes the language and imposes restrictions on its use. The more I learn about mikroC the more restrictive I find it, pity these limitations and restrictions are not published.

If I need a stack in my own projects and one isn't available as a native library I write one. The way you have implemented this means the developer has no control over the stack, can I set the amount of RAM that is available for variable usage?

Normally, one can set the stack size to a specific size and then work with that.

The job of the compiler is not to second guess the developer, just to translate what the developer writes into native machine code. If I want to write a routine that calls itself a number of times then I should be able to do it, without the compiler poking its nose in. If I write something that crashes the PIC thats my problem and I can fix it, however if the compiler just blanks it, it really limits product development.

Are these same restrictions present in other C compilers for PIC16F and 18F?

[zristic]

Cant you use heap for that? Heap is available in mikroC pro for PIC.

[Sy]

For what? Please explain.

[rajkovic]

Thank you for the reply.
The approach you have taken isn't good, why didn't you create your own stack in RAM? And just push and pop directly to the allocated area of RAM for stack space?
The approach you have taken changes the language and imposes restrictions on its use. The more I learn about mikroC the more restrictive I find it, pity these limitations and restrictions are not published.
The job of the compiler is not to second guess the developer, just to translate what the developer writes into native machine code.

for PIC16 you can not have HW stack

For p16enh and p18

As a many things in life we had to make choice would we go with compiled stack approach which is natural solution for architectures that does not have good support for hardware stack or to try
to emulate it with existing instruction set which is not built for that purpose. There is no PUSH and POP instruction for managing data in RAM in PIC

we have decided to use compiled stack approach because it makes possible to generate more efficient code and have only restriction in terms
of forbidden recursion and reentrancy.
Microchip has added extended instructions to standard P18 set for newer devices
The extended instructions are specifically implemented to optimize re-entrant program code.
But it is only 8 new instructions and still you will have to have overhead in code.
In order to have emulation of stack you will have to use at least 1 FSR for this purpose
Also accessing local in compiled stack does not need any preparation but
in order to have it accessed as Software-implemented stack it will take much more instructions.

general conclusion is
Software-implemented stacks are not efficient, so it is difficult to generate reentrant code and support local variables in PIC18.
It is not impossible but it is quite inefficient.

We therefore decided to go with compiled stack.

The job of the compiler is not to second guess the developer, just to translate what the developer writes into native machine code.

Compiler is doing exactly that and limitations are documented in Help.

chapter

PIC Specifics
Nested Calls Limitations
lists next limitation

Nested call represents a function call within function body, either to itself (recursive calls) or to another function. Recursive function calls are supported by mikroC PRO for PIC but with limitations. Recursive function calls can't contain any function parameters and local variables due to the PIC’s stack and memory limitations.
also it is linked to reentrancy limitation.

[Sy]

Ok, ty for reply, still struggling to see where the difficulty and ineffeciency is. A stack is a pretty simple beast, a block of memory with a pointer, what could be ineffecient about that? Its just the same as using RAM except instead of reading from a fixed location you pop the next instruction off the stack.

So the PIC might not have a PUSH or POP instruction, write one, PUSH is just writing to the pointer with an mem move down, POP is just a read from the top of the stack with a mem move up.

It isn't rocket science, I've tried using the pragmas for reentrancy without success.

[octal]

So the PIC might not have a PUSH or POP instruction, write one, PUSH is just writing to the pointer with an mem move down, POP is just a read from the top of the stack with a mem move up.

try to do it using PIC16 assembly and you'll understand why it's inefficient. From your posts, we can see you never wrote asm code for PIC16. Writing a simple PUSH means incrementing your (soft) stack pointer, and writing the value to pointed location. Doing that is simply at least 4 or 5 instructions at min (unless you sacrify your second FSR).
Doing the reverse will be the same overhead.
Compiled stack is, instead, a simple write or read of a (global) RAM location, and reuse of most ram locations for non reentrant routines.

[Sy]

True I haven't written PIC assembler before, I have written assembler on other processors. The advantage of using C is so I don't have to write assembler.

[octal]

most of the constraint mentionned by zristic are du to the special nature of PIC architecture. If you need to find something equivalent or at least 80% working the same way as most of other processors (8085, Z80, 68xx, ....), you better switch to PIC24/dsPIC or PIC32.
Writing a structured language compiler for PIC16xx is really a challenging task. PIC architecture has not been specially built with structured programming in mind. Things are quite different for PIC24/dsPIC/PIC32.