Reentrant?

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....

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?

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%

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

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....

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?

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%

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

"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 :)

Its late here on the East Coast of the USA on a Friday night, and while I was/am in my home-officeI noticed the response level jump up on my 'reentrant' question.

Arroogah! Arroogah!

Status: Code RED.

Action: Deploy tactical ramble.

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).

Rather than the many of somebody else's kids who die in your fantasies?

It is fun to make fun of you Jack, so sometimes I do it just for that 'fun' reason, and without malice

I didn't realise you usually did it with malice. How very upsetting.

Ramble Factor: 100%.
Content Factor to fish-heads: 0%
Content Factor to other Triple-Nine members: 100%

Well, I guess if that's the way the stats pan out, I'm in with the fish heads.