|
Errors in my program ??? IMPOSSIBLE !!!
Hi, Ernie
Just because you're supposed to think to everything happening ... and of course because you're an " up to the top " PbP programmer ...
...
Thinking to that ... there's a CARRY BIT that exists in PICS ... I bet 1$ it is not automatically cleared by PbP ( ... ) in an overflow situation.
Just an idea ...
regards
Alain
Last edited by Acetronics2; - 12th October 2006 at 15:38.
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
|
Go ahead and bet your dollar. I'm using PBP for software in a human patient connected device. If my device fails to work when it's supposed to that person will die.I bet 1$ it is not automatically cleared by PBP ( ... ) in an overflow situation.
You can bet your buck but I'm not betting someone's life on an undocumented "feature."
I do code very defensively when using integer math; typically checking inputs for values in the expected range to keep the output from overflowing is sufficient.
|
10 Bucks to see ...
Hi, ErnieOriginally Posted by ErnieM
Great to you, but, as the source code is available ( PbP**.lib ), you can verify it quietly. Add to that it can easily be verified " live ( ! ) " in a little test example, using MPLAB in debugging mode ...
One more thing ... I remember having read somewhere those softs do not guarantee they are bug free ( special lines for life critical systems , last page of the manual ... also saw that lines from µChip datas !!! ).
Sooo , documented or not, it's all at your own risks ... and you have to verify everything.
Just for fun ... most of my systems are intended to care of the flying security of giant size model aircrafts ...
We're aboard the same boat, it seems ...
Regards
Alain
Last edited by Acetronics2; - 13th October 2006 at 19:59.
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
|
And my code is used by Lockheed-Martin, Northrup Grumman, Boeing, British Aerospace, General Atomics, Raytheon, Rockwell-Collins, Smiths Aerospace, Fermi Labs, Lawrence Livermore Labs and others. So I need reliability as well.
Charles Linquist
|
If you were to bet any amount of money on the carry/borrow flag being correct after a math operation in PBP, you would lose. Because there are several instances where it ends up wrong.
Being capable of only 16-bit math, they apparently weren't worried about anyone using larger numbers and took shortcuts in the math routines to save a couple words in the compiled code. Causing me many days of headaches, because I originally thought it would have worked correctly.
Essentially it boils down to the possibility of 2 overflows in a 16-bit operation. And the PBP math routines only account for 1 of them.
Sure makes 32-bit math a pain in the asparagus.
<br>
DT
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks