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
Oh dear - back to school, Christoph.
My copy of K&R states that C functions can be called recursively. This implies that functions are considered reentrant by default, at least by the compiler.
(Of course, the programmer can still make functions nonreentrant, e.g. by using static variables)
Care to point out where I'm going wrong here?
Sprat...
"For the record, I worked with people who helped develop the ANSI Standards for "C" not C itself.
Er, yes Vince. As you wish.
Just a thought, but you have surely published enough of your fantasy cv in this thread to reveal your fantasy identity to another talented Googler?"
Well, hmmmm. The disbelief is because I guess a 'talented googler' could create such a world.
Of course I have my own photos and videos that nobody could find on the internet, so I can 'prove' my bonafides. To do so would take me time to deal with generating some kind of link to some public picture viewing site.
Two problems with that: 1) I don't care if you think it is a fantasy... (but I guess I care enough to even respond to your insistence that I'm making it up), and 2) I don't want to spend the time to find out how to publish such images and videos to some public url.
And yes Mr. Sprat, I did notice your appreciation for my contributions---thank you.
As far as reentrancy being 'standard' ... that depends upon the processor and its capabilities. This is part of the Embedded World, so the luxury of enough RAM etc, do not always allow this reentrant capability. Therefore, companies, like Keil, will make special provisions to allow reentrancy.
There are many-many controllers in the world, and many-many compilers. Just because the 'help file' or 'on-line help' doesn't specifically address it, doesn't mean that the pragma isn't required. Thus it is prudent to ask.
...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
That is known as 'humor'.... and for those across the pond, 'humour.'
Sure:
The world of 'C' was standardised by ANSI in 1989, subsequently it has been governed by ISO. K+R may have made promises about reentrancy over 20 years ago, ANSI/ISO have not. K+R is a great book to learn the basics of 'C' from but you really need to get a decent modern reference such as H+S or the ISO standard itself.
Yes sir! Right away sir!
Mmmm...
Of course I have my own photos and videos that nobody could find on the internet, so I can 'prove' my bonafides.
Well yes, of course you do.
To do so would take me time to deal with generating some kind of link to some public picture viewing site.
Oh - sounds complicated. You are a busy man, after all.
Two problems with that: 1) I don't care if you think it is a fantasy... (but I guess I care enough to even respond to your insistence that I'm making it up),
Mmmm....
and 2) I don't want to spend the time to find out how to publish such images and videos to some public url.
Well, of course not.
My pleasure Vince - keep them coming.
As far as reentrancy being 'standard' ...
Oh - who said that?
that depends upon the processor and its capabilities.
No, it depends on the compiler function call implementation.
This is part of the Embedded World, so the luxury of enough RAM etc, do not always allow this reentrant capability. Therefore, companies, like Keil, will make special provisions to allow reentrancy.
I see. So you may not be able to have reentrancy unless the compiler provides a function call implementation that allows it? Congratulations!
Perhaps so - but it was clear from your question that you thought that reentrancy was, in the general case, a feature added by the compiler manufacturer rather that a natural result of a stack based function call convention. What could possibly lead you to imagine that the calling convention for the ARM compiler would prevent reentrancy?
What relevance does this have to me?
K+R may have made promises about reentrancy over 20 years ago, ANSI/ISO have not.
I don't know what kind of substance you're on --- but you do need to reduce that dosage, lest those hallucinations get even worse.
Oh, and just in case sarcasm doesn't get through to you: of course Standard C does require that functions can be re-entered.
Would you care to back that statement up with a reference to the 'C' standard?
Its late here on the East Coast of the USA on a Friday night, and while I was/am in my home-office, I noticed the response level jump up on my 'reentrant' question.
Lots of vitriol, but some funny stuff too.
I do prefer that these threads continue on the bottom, and make reference to comments above versus immediately after a statement and forcing the reader to take note of the date/time they were posted.
That said, I am 'adding' some more rambling here at the [current] bottom of the thread.
The most relivent point I saw was Jack Sprat's (aka Sardine, aka Fish Brain) point about my origional post....
I've been in the embedded world so long that I never assume full compliance to standards that mostly apply to relatively 'large' systems like the PC with its GBs of RAM, and ultra fast CPU yet totally non-realtime construction. So when I did ask it wasn't out of the lack of " first year computer science " but rather out of the known limitations of implementing 'standards' on the lesser processors, or processors/controllers with special limitations.
So to be more than "99.99%" sure I indeed asked this forum since I know that the help-files are usually out-of-date with respect to the current IDE toolchain system being used.
The architecture I use for implementing embedded code requires me to separate out [potential] non-standard implementations due to the tool or IDE so that, by contract, another company or government agencies can regenerate the required source code as it was intended.
This means that they might be using IAR, or some other compiler that is slightly different (as they all are) than the official standards or implementations of such on one IDE versus another.
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.
So when I 'asked' the question, I was in the process of 'commenting' the special requirements due to the IDE development tools required to generate the proper executable. The use of 'Reentrancy' is is specially identified in my rule-book as a cautionary issue.
Again, this is all covered in my "Rules for Radical Code Monkeys" book and complies with many of the Aero/DoD/MIL/FDA/etc high-reliability requirements. (Remember that phrase "High Reliability" doesn't mean that 'only' one out of 10,000 fails is an 'acceptable' number when it is one of your kids who died due to some code-monkey's stupidity).
I know for a fact that 'other people' will be taking my source code, and I must first create it so that the sardine brains will be capable of getting it right when they decide to modify the source to account for some replacement part or some other issue at hand.
So although you might think it is 'standard' practice to just assume that every function be re-entrant, I've been in this business long enough to know that if the processor is changed, which REQUIRES the a special (very typical in the embedded world) pragma, then they can easily identify this risk item when they take over these R&D projects during a time when it went from R&D into full production.
So that ARM processor, with its fairly powerful architecture might get reduced into an FPGA, and then an ASIC. This is where non-essentials are removed from that 'standard' processor/controller that it was first developed under. This is done in order to squeeze out every gate or real-estate they can in order to fit it into the cost-reduced high-volume production.
By separating out such potential issues into seprate modules, headers, etc, the transfer to the FPGA/ASIC stage becomes a lot easier to manage when the core architecture is highly clear on what the development requirements were, and the engineer's ability to quickly find these 'needed' items to conform to the new platform.
Ever play chess? Turns out that the further ahead you 'see' things, the better your odds are of winning. I like to win... even if it takes years to show that the work I did pays off in the end.
Those who have worked with MY code and MY rules for developing embedded systems have indeed found it easy to convert MY stuff into a new platform.
Well, I've played chess, and I've been on that side of the FPGA/ASIC world, So I 'see' ahead when I do some 'new' R&D work so that the transistion is far less painful than working with Spratter-brain's source code.
(It is fun to make fun of you Jack, so sometimes I do it just for that 'fun' reason, and without malice).
Ramble Factor: 100%. Content Factor to fish-heads: 0% Content Factor to other Triple-Nine members: 100%
"Rules for Radical Code Monkeys" book
I can't but help think that this book is like the legendary "space core directives" from Red Dwarf.
Vince keeps quoting from it, but I've seen no evidence of its actual existance.
Heck - If it does exist, I shudder to think how much of a carriage surcharge Amazon would put on it to cover excessive weight. Looking at Vince's writing style, it must have a record number of pages.
DVDs has been in existence for a great many years now. Dual-layer DVDs would fit over 9GB of text and text-art without any weight penalty.
The biggest problem is to plan which year you would have read through the document and could start planning to begin work on a new project again - if the document is too big in relation to the retention times of the readers, then you may have to spend the rest of your life just running the refresh loop :)
"Would you care to back that statement up with a reference to the 'C' standard?"
I note you're always quick to call on others to refer to the Standard - haven't you done it yourself?
How about:
ISO/IEC 9899:1990 (E)
6.3.2.2 Function Calls
Recursive function calls shall be permitted, both directly and indirectly through any chain of other functions
(my emphasis)
Maybe also:
5.2.3 Signals and Interrupts
Functions shall be implemented such that they may be interrupted at any time by a signal, or may be called by a signal handler, or both, with no alteration to earlier, but still active, invocations' control flow (after the interruption), function return values, or objects with automatic storage duration.
The standard does note that functions in the standard library are not guaranteed reentrant.
Yo... Silly,
The only real exposure into the book...
/* *************************************************
http://www.keil.com/forum/docs/thread14795.asp
(The exeperpt/post from it....)
RE: A rare glimpse into my world...
This is from my code-monkey rule-book (aka "Rules for [Radcial] Code Monkeys")
I rarely give out this type of valuable information, so you (and every forum reader) better appreciate it...
COMMENTS
Generally "Comments" are either Strategic or Tactical in nature. While some comments can be categorized as Orientation. (I did use the word "Theaterical" as in "theater of war" but that was a bit 'dramatic' so I chose the word 'Orientation' instead)
Strategic comments describe what a section of code is supposed to accomplish. Strategic comments should be placed before the code section that implements the task.
Tactical comments describes the specifics on how the code is implementing a task. Typically these tactical comments are on an end-of -line basis. Tactical comments serve to enlighten the non-obvious behavior or method implemented, and not a re-statement of what the code performs.
Orientation and Strategic are closely related, but they do differ. Orientation comments provide the reader with a wider conceptual view of the code module. Orientation comments can be information about the system's environment like the OS, CPU, Memory, IDE, Versions, etc. While Strategic and Tactical are the dominant forms, Orientation should be still be contained in all source code modules.
The over-use of tactical comments will result in source code that takes too long to read, and begins to devalue and hide the worth-while comments. Strategic comments should be the primary and dominant form of commenting source code.
Tactical comments should be as detailed as needed to inform the programmer. The common used for Tactical comments is when describing the side-effects of code implementation or when the code performs something that is not obvious to the standard or novice programmer. Always write on a level that is explanatory the reader, and never assume the reader is as competent as you think you are.
Tactical comments in "C" typically use the double-slash notation, while the Strategic comments are flower-boxed. Orientation comments are typically found at the top of the module.
************************************************* */
Yes, there is more about commenting, but that will suffice for now.
I'm sure your 'rule-book' has something similar. As far as verboseness goes, I can actually get to the point, but sometimes you have to write on a level far lower than you would expect.
The terseness of words selection is indeed correlated to the 'level' of one's audience, so sometimes more words are required to convey the same concept that would otherwise be more concisely stated.
And FYI, if you search the old IEEE archives, you'll find an article about "Typographical Noise" where simple things like SPELLING IN ALL CAPITOLS, THE READER IS SLOWED DOWN BY 50%, where as lower case doesn't. There is a lot of information out there, and how to best convey it to silly people or even, like The Incredible Mr. Limpet, communitacting with fish.
An example of my "pretty distinctive style" (thank you Andy) can be found here too: http://www.keil.com/forum/docs/thread12890.asp
But even that isn't exactly a 'prime' example of implementing 'the book' as it is written.
Generally speaking, I don't divulge much from MY 'book' to just anybody.
(And FYI... I can't spell worth a darn, so Spell-Check is a very active part of my documentation--my wife, on the other hand, spells everything properly)
"...I can't spell worth a darn..."
My rule book is nowhere near as voluminous as yours, but there is one item that was added a while ago.
It was a simple entry, that just stated:
Keep the spell checker switched on.
Why? because we had one coder here who's spelling was attrocious - In his comments, in his documentation and (all too frequently) in his code. For example, he would frequently spell access incorrectly, the strangest form was axcesss.
When asked in a meeting why he didn't use his spell checker, he glibly replied:
"I do, but only when I don't know how to spell something."
There were a lot of open jaws around the table!
I think that would work only if you had a spell-checker that could be confined to comments & strings?
"I think that would work only if you had a spell-checker that could be confined to comments & strings?"
The text editors we use have that ability (with the help of some custom macros).
Spelling Issues:
I once worked on a commercial product and wrote the configuration interface for the DOS user (Pre-Windows), and I had to deal with the cursor, and had routines labeled 'cursor' and 'curser' (they did different things) in my code.
In my "Help Files" I misspelled cursor a lot. This was back in the pre-email days, so I got lots and lots of letters and phone calls about MY poor spelling.
Needless to say, it was embarrassing.
Basically, all 'help files' (or any text the user will read) should be spell-checked using an editor that has that capability, along with with grammar checking.
Then these files should be peer reviewed before it is incorporated into the source code.
In addition it is clear that the function names should not look so close to each other either. (Yes, more 'rules').