Carry and Borrow Indication

Over the last few years the restrictions caused by the PICAXE's positive-integers-only numbering system has been discussed several times. I can understand the reasons for these restriction in the early days: limited firmware space, limited variable space and a desire to keep the PICAXE really simple to use, being just three.

While some others have asked for more complicated number formats like signed or even (gasp) floating point variables, I can see the value of keeping everything really simple for an entry level microcontroller and an entry level programmer.

I thought I'd open a discussion on the pros and cons of the PICAXE firmware having a read-only Carry bit available to the programmer. This would be set and cleared according to the last arithmetic operation: Carry (variable overflow) or borrow (variable underflow). Most importantly, this user-accessible carry bit would not change the way any existing PICAXE code works.

My current thought is that the firmware would initialise the Carry bit as 0 as the start of every Let (or implied Let) statement and set it to 1 whenever an overflow/underflow occurred during that calculation. My idea is to allow experienced programmers to determine when the result of a calculation has overflowed the limits of a byte, word or bit variable more simply.

Thoughts, anyone?

I too queried about the possibility of a Carry/Borrow flag, but the consensus was that it would add too much to the limited firmware space.

However, a similar function could easily be added to the simulator, which would at least help in debugging.

In general, I think it's time for X3.

although this isn't really an answer - if you were to restrict you variable to 32767 for a word and 127 for a byte you could use the final bit for a flag - downside would be you would loose half the capacity of the variable which would most likely force the use for more word variables in place of a byte variable.

the one thing that maybe better and actually solve more problems is an interrupt that is triggered from variable values. not only could this set a flag to indicate and issue, it could also be used for triggering events. as it currently stands you have to check the variables manually for the given state. I am not going to suggest that every variable should be checked - that would take way too long - but one or two specified variables to be checked would be quite helpful

While there may be something to be said about keeping things simple, there is not yet support for simple math braces/brackets or signed integers. Why then would anyone suppose that a carry bit or other math enhancements would be even be considered?.

that the nice idea behind the carry bit, it could quite easily be used to indicate a negative n + number of possible values = negative version of itself as it will overflow (ie if you want b0 to equal -3 b0 = b0 + 256 would trigger carry bit and cause a negative)
things with this would get tricky if you start trying to add signed bits - things get a little more complex with things like -0 and +0 and forces inverting bits for maths to actually happen
mathematical parenthesis (brackets) in theory could be implemented but would require the software to scan the sum, find the brackets, do that stuff and hold the answer/s in a temporary variable before doing the rest of the sum - mathematical order of operations would be nice too, but you face the same issues as you do with parenthesis. hardware adders and alike ignore these issues and only add 2 inputs, it is down the CPU that puts input to solve that problem, which it uses huge numbers of cycles to solve, but most have many more cycles and programme space than most off the shelve processors.

heres quite and interesting video twos compliment
https://www.youtube.com/watch?v=lKTsv6iVxV4

positive and negative adding
https://www.youtube.com/watch?v=WN8i5cwjkSE

and floating point rounding error - something that needs to be taken into account
https://www.youtube.com/watch?v=PZRI1IfStY0

maths isn't a simple thing for a machine to do, it just does a lot very fast, think that multiplying is adding a number of times 6000*6000 is 6000 added 6000 times over (6000+6000=12000+6000=18000... eventually = 36,000,000). lf you look at some of the floating point picaxe programmes that have been written the complexity speaks for itself.

Hi,

Goeytex said:

Why then would anyone suppose that a carry bit or other math enhancements would be even be considered?.

Click to expand...

+1. I must declare that I find the omission of a Carry/Borrow flag the most frustrating (and surprising) omission from PICaxe Basic. It's the most fundamental feature of every (other) microcontroller that I've ever programmed.

But it's not going to be implemented in the PICaxe (raw chip's) interpreter, so the question is whether it could be added into the Program Editor (in a similar way to "INC var" being simply replaced by "var = var + 1", or a very recent thread on "FOR ... DOWNTO"). That might save a little typing, but perhaps not much else.

Of course bit8 and bit24 are effectively Carry/Borrow flags if w0 and w1 are considered as byte variables, but I guess that under/oveflows and shifts from 16-bit variables would be rather more difficult to handle. Also forget any thoughts of generating an "interrupt"; PICaxe Basic doesn't even have a run-time "Error-Handling" strategy, let alone any "Exception" capability.

There are a few "tricks" which are no more complicated than testing a Carry flag, for example after a 16-bit addition (C=A+B) then if C<A (or C<B if more convenient) then a Carry must have occured (otherwise it didn't).

Cheers, Alan.

AllyCat said:

But it's not going to be implemented in the PICaxe (raw chip's) interpreter...

Click to expand...

Why not? It seems a logical step (pardon the pun) to me: I not defeated yet . I don't think it would add huge amounts to the firmware. Perhaps it's not possible to be included in the M2s or X2s but I'd like to see the PICAXE evolve beyond some of its current limitations.

Error interrupts? Now that's an interesting one but it might test the limits of the available firmware space.