# Borrow and Carry Bit for Subtraction

Similar to the usage of the carry bit when adding there are mechanisms for subtracting that allow to integrate the result of subtraction of the lower bits into the subtraction of the next higher block of bits, where necessary.

There are two ways to do this, that are trivially equivalent by a simple not operation:

• borrow bit (also borrow flag)
• carry bit (also carry flag)

Often CPUs use what is the carry bit for addition and interpret it as borrow bit for subtraction.

Here are the two ways:

## Borrow Bit

It is assumed, that the CPU-word is bits long, so calculations are performed modulo . Further it is assumed, that the range is preferred, so all sign issues are excluded for the moment.

When subtracting two numbers , from each other like and , the provided result is

and the borrow bit is set (), to indicate that the subtraction caused „underflow“, which had to be corrected by added in order to get into the desired range.

In the „normal“ case where , the provided result is simply

and the borrow bit is not set ().

The next round of subtraction takes the borrow bit into account and calculates , where the condition becomes and the result is

or

respectively. This is how some of the older readers used to do it in school on paper, but of course with .

Now the typical integer arithmetic of current CPUs uses Two’s complement, which means that . Combining this with the previous results in calculating

At this point some CPU-designers found it more natural, to use the carry bit instead of the borrow bit .

## Carry Bit

When subtracting two numbers , from each other like and we have , the provided result is

and the carry bit is not set (), to indicate that the subtraction caused „underflow“, which had to be corrected by added in order to get into the desired range.

In the „normal“ case where , the provided result is simply

and the carry bit is set ().

The next round of subtraction takes the borrow bit into account and calculates , where the condition becomes and the result is

or

respectively.

Now two’s complement with this can be written as

or with

These two ways are really equivalent and easily transformed into each other. Neither of them provides big advantages, apart from the fact that we have the unnecessary confusion, because it depends on the CPU design, which of the two variants is used.

## Recovery of Borrow or Carry bit

The borrow bit is calculated and used during subtractions that are done at assembly language level, but higher languages like C or Java do provide access to this information. It is relatively easy to recover the carry bit in the case of addition based on , and .

This possible as well for the subtraction. Quite easily the comparison between and or could be done before the subtraction. This would work, but it is kind of inefficient, because under the hood the comparison is just a subtraction with discarding the result and keeping the flags. So the subtraction is performed twice. This might not be such a bad idea, because a compiler could recognize it or the work of subtracting twice could be neglectable compared to the logic for an „optimized“ recovery, based on some logic expression of certain bits from , and .

# Poor mans profiling with LOGs

We have professional profiling tools and we should use them.. They give really useful and extensive information.

So why bother about doing „poor man’s profiling“?

About ten years ago, running profilers was kind of constrained to very small examples and computers with really huge memory. We have this huge memory now on every development machine. But we can only run such tests on development and test systems.

Sometimes it is possible to copy data from the productive system to the test system and really simulate what is happening on the productive system. Often this is quite far away from what is really happening on the productive system and we often only know about a problem when it has already occurred.

What we usually do have are log files. Each entry has a time stamp and can somehow be connected to a line of code where it is created. We always know the class or the file or something like that from where the log statement was issued and since there is only a limited number of log statements, they can often be recognized. Sometimes it is a good idea to actually help finding where it was logged. For example could we artificially put the source code line number or some uniq number or a short random string into the source code for each log statement. Then we can find several pieces of information in the log statement:

• The timestamp (please use ISO-format!!! And at least milliseconds)
• The source code location (line number, class name, random string, relative position in file, meaningful description like entering/leaving methods etc.)