We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I rarely ask questions on this forum, but since I couldn't [easily] find it in the help-files, or on-line, I'm asking you guys.
I usually (like never) don't use the 'reentrant' pragma, but I think I may have to do that with a particular routine.
BUT I can't find the key-word that declares a function as reentrant. Am I missing something? Is there one for Keil's IDE tools? If so, what is its form? Can I get a link to the 'official' use of it?
Thanks in advance, and I need it asap because I need to pass this class and I don't want to really learn how to do this 'embedded' stuff anyway but the teacher keeps hounding me.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
Surely, for functions to be suitable for calling recursively, they have to be reentrant?
When working with real processors with a normal stack, I would say that making a function non-reentrant is a design choice by the developer.
'Reentrant' implies rather more than 'recursive'.
No, Mr. Sprat. For the compiler, the possibility of recursion implies reentrancy. It's as simple as that. Hence, standard-compliant C compilers must produce reentrant functions by default.
It's basic logic, really: (recursive function calls allowed) -> (functions must be reentrant). Since you like using your brain, this should be very obvious to you. Feel free to retract your snide comments now.
(Of course, the programmer can decide to make a recursive function nonreentrant, but the compiler may not do so.)
Without further feedback from Jack, I am left to speculate: I think Jack was referring to interface changes needed to guarantee re-entrance, while recurrence is more an implementation issue.
Robert McNamara -> The ARM calling convention, as defined does not require
Cpt. Vince -> The use of 'Reentrancy' is is specially identified in my rule-book as a cautionary issue.
Jack Sprat -> 'Reentrant' implies rather more than 'recursive'.
Cpt. Vince -> The architecture of my software allows non-standard pragmas to be issolated and documented well so that ten years from now (or more) the code can be updated, recompiled, rebuilt and still perform AND PASS the required testing.
=>allows non-standard pragmas to be issolated and documented well<=
Sorry for that, I am confused.
non-standard to ARM calling convention? or non-standard to C standard?
Is the use of 'recursive' also specially identified in the rule-book as a cautionary issue?
I am not sure if I am capable to understand all these, but I guess I should catch this opportunity.
For the compiler, the possibility of recursion implies reentrancy. It's as simple as that. Hence, standard-compliant C compilers must produce reentrant functions by default. Although what you say is in part correct, could confuse people, the term reentrance is usually used with concurrency in mind not reentrancy. Reentrance: could ocurre when there are recursion, mutithreading or interruption happening asynchronously, and in these last cases the thing is more tricky and the compiler is not enought to make it reentrant. The compiler will just push the actual set of register into stack every times that enter to a function, wont care if has or not the same function signature.
It's basic logic, really: (recursive function calls allowed) -> (functions must be reentrant). Since you like using your brain, this should be very obvious to you.
When you start from a false premise you sure can come to a lot of wrong conclusions!
Feel free to retract your snide comments now.
I think I'll stick with them, thanks.
What troll started this thread?
Zeusti/
Always our freind, and yo'rs and yo'rs
When you start from a false premise you sure can come to a lot of wrong conclusions!<p>
The premise is "Recursive functions are permitted". Andy quoted the relevant part from the standard. If you're going to dispute that, you'll have to come up with a little more than jumping in circles and yelling "it's false, it's false!". Nebulous assertions don't make any argument at all, Mr. Sprat.
In that case, just keep making yourself ridiculous. You're doing a such a fine job.
As I tried to say (in a previous post in this thread), in the embedded world many of the 'standards' cannot be easily implemented by the 'lesser processors' like the 8051.
So the compiler companies will sometimes deviate from the standard and require special pragmas or compiler/linker switches to allow for the code to generate full compliance. I am aware of this, and the processor limitations, and the challenges of compiler vendors, so in 'my book' it is a "cautionary" issue because of what Leandro Gentili said. (He said it very well too).
I also tried to say that sometimes a design is either optimized and changed. this can include the processor itself. "C" is fairly transportable from processor to processor, and can be 'transported' into VHDL for FPGA/ASIC needs.
If your software is organized properly, these transitions can be more easily handled *IF* you are aware of these potential issues.
I was the 'troll' that started this thread. *They* expanded it. The answer came after the 3rd reply by Robert McNamara.
Note that in one way, reentrant can be seen as less than recursive or more than recursive.
Recursion means that the same execution thread may call the same function again - directly or with a number of other function calls in-between.
A reentrant function can have multiple visitors from multiple call chains - such as a RTOS performing a task switch inside the function, and letting a new thread call the function at the same time.
A reentrant function would be expected to allow recursive calls, but a function that allows recursion may not be able to support reentrant calls.
A recursive function can control where it is, when it invites itself to further recursions. A reentrant function may be anywhere where a new thread tries to enter the function. The asynchronous events of a reentrant function is similar to signal handlers or interrupt handlers.
Recursion is just a question of stacks, and saving used registers. With a reentrant function, you may also have problems that the compiler creates code sequences or calls helper functions that are not atomic and where you may not call the function again during this code sequence.
The standard is way more clear about recursion than it is about reentrant functions.
The compiler vendors normally generates reentrant code, and leaves it to the developers if we call any non-reentrant RTL function or are playing with static data or simmilar.
The big problem is that compiler vendors don't spend any real time describing their generated code, and any use of helper functions for FP emulation, or arithmetic of 64-bit numbers or similar. They don't explicitly tells us what is, and what isn't reentrant.
In the end, a lot gets down to beliefs, trust, hope, prayers, ... and is one of the reasons why embedded developers so often spend time now and then reading through the generated code. It is also a reason why you may have to certify not only your product but also your development tools.
I now know why you're first name is Per.
Perfectly stated.
oops...
your not you are (you're) ... (not grammar checked)
We are just dieing to know what the false premise was, Jack.
I guess I should catch this opportunity. (Sorry for my limited English ability.)
Stage-A: You have processor-A and compiler-A, these are able to support A1/A2/A3. Stage-B: Then, you downgrade your processor to processor-B, and get a compiler-B, these are able to support A1/A2, but do not support A3.
So, at Stage-A, you write down a cautionary about A3, and isolate A3.
But how do you know that processor-B/compiler-B do not support A3, at Stage-A? Do you have a processor-Essential and compiler-Essential as a Standard?