Overflow bit?

[Charles Linquis]

PBP has a bunch of system variables, does it have any that I can test for overflow? In other words, is there NO way I can find out if the result of an addition or multiplication led to a variable overflow? Must I do the math in assembly to get that information?

[Acetronics2]

Hi, Charles

IF the result of an addition or multiplication is smaller than one of its terms ... there was an overflow !!!

an so on ...

Alain

[mister_e]

Euh... lower than the Higher term is probably better IMHO Asumming 1*10, 10*10000, etc

[Acetronics2]

Euh... lower than the Higher term is probably better IMHO Asumming 1*10, 10*10000, etc

And WHAT's wrong then, Mr Super E ??????????????????????????

Cheers !!!

Alain

[Charles Linquis]

Makes me wonder why I didn't think of this before!

[ErnieM]

[quote]Makes me wonder why I didn't think of this before!{/quote]

Actually, I wonder why the authors of PBP didn't think of this in the first place, and set a readable flag that would indicate an overflow/underflow condition.

[Acetronics2]

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

[ErnieM]

I bet 1$ it is not automatically cleared by PBP ( ... ) in an overflow situation.

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.

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.

[Acetronics2]

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.

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.

Hi, Ernie

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

[Charles Linquis]

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.

[Darrel Taylor]

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>