The BLE (Borrow Look Everywhere) is a subtractor that uses CLE logic. It is pretty simple surprisingly enough. Could even replace addition logic.

The Logic Behind Subtraction - The Half Subtractor

Let's look at a truth table for the half subtractor first.

As you can see, the output looks exactly like the output of an XOR, with the exception of the minus of course.

So in order to output -1, we need to borrow from the next bit. When do we borrow? that's only when B > A. The logic gate we can use for that is B Nimplies A. Now we got an output for the borrow.

Now that we have a half subtractor, let's look into why we can just combine 2 and it becomes a full subtractor.

The Full Subtractor

- RC Subtractor

So just like in an RC adder, you simply put two half subtractors onto each other and OR the borrows. But the reason it works is as follows.

First off since the output of the first half subtractor is supposedly positive, it is supposed to go into the addition input of the second half subtractor, which in this case is A. The borrow is a negative value however, we are subtracting 1 from the next bit when we borrow from it, so it goes to the subtraction input which is the B input in this case. Pretty logical thus far, right?

Now just like in the adder, the borrows are OR'd and you get a ripple borrow adder. You can OR the two borrows together simply because the borrow from one half subtractor can not be on at the same time as the borrow from the other half subtractor. It's simply logic, you can try it out for yourself and try to figure out why. For now it's not important.

- BLE

The borrow look everywhere logic is by far the strangest shit I have dealt with. But I managed to pin it down. I'll need to compare it to the CLE adder to explain it well, though.

so CLE logic is basically minecraft optimised CLA logic, which uses instant diodes. In real life, diodes are not instant. CLA logic can be defined as the addition technique where you literally just calculate all possibilities of a carry before calculating the end result. Let's create the truth table for the borrows. I'll call the generation of borrows for generate and propagation of borrows for propagate, just because I don't know the correct terms for these or if those are even the correct terms.

In order to propagate a borrow, you need 0, right? We get that propagate is XNOR because we get a 0 when inputs are equal. Now in order to generate a borrow, we need to use the generation of borrows explained above. We get that generate is B Nimplies A

That's it, now you have your borrows. For your second half adders it's simply a matter of XORing the borrows and output from first half subtractors together as we have concluded beforehand.

I have built it and this is the result, I made it into an ALU pretty easily. Only thing with this particular design is I made the OR be B Nimplies A instead. Not really necessary, but my first XOR was based on 2 Nimplies gates OR'd together so it was easier to make it as such

My subtractor is however poorly optimized and slow, it acts for the most part as a proof of concept. I haven't bothered to count how long a calculation might take, but if I have to guess, it's prboably 5-7 ticks. Yes, it's also non-synced. I believe however that I could easily boil that down to 4 ticks synced. I will definitely be looking into it, but for now, this is it. To get to this subtractor, you can do /warp BLE.

- Pablo

The Logic Behind Subtraction - The Half Subtractor

Let's look at a truth table for the half subtractor first.

As you can see, the output looks exactly like the output of an XOR, with the exception of the minus of course.

So in order to output -1, we need to borrow from the next bit. When do we borrow? that's only when B > A. The logic gate we can use for that is B Nimplies A. Now we got an output for the borrow.

Now that we have a half subtractor, let's look into why we can just combine 2 and it becomes a full subtractor.

The Full Subtractor

- RC Subtractor

So just like in an RC adder, you simply put two half subtractors onto each other and OR the borrows. But the reason it works is as follows.

First off since the output of the first half subtractor is supposedly positive, it is supposed to go into the addition input of the second half subtractor, which in this case is A. The borrow is a negative value however, we are subtracting 1 from the next bit when we borrow from it, so it goes to the subtraction input which is the B input in this case. Pretty logical thus far, right?

Now just like in the adder, the borrows are OR'd and you get a ripple borrow adder. You can OR the two borrows together simply because the borrow from one half subtractor can not be on at the same time as the borrow from the other half subtractor. It's simply logic, you can try it out for yourself and try to figure out why. For now it's not important.

- BLE

The borrow look everywhere logic is by far the strangest shit I have dealt with. But I managed to pin it down. I'll need to compare it to the CLE adder to explain it well, though.

so CLE logic is basically minecraft optimised CLA logic, which uses instant diodes. In real life, diodes are not instant. CLA logic can be defined as the addition technique where you literally just calculate all possibilities of a carry before calculating the end result. Let's create the truth table for the borrows. I'll call the generation of borrows for generate and propagation of borrows for propagate, just because I don't know the correct terms for these or if those are even the correct terms.

In order to propagate a borrow, you need 0, right? We get that propagate is XNOR because we get a 0 when inputs are equal. Now in order to generate a borrow, we need to use the generation of borrows explained above. We get that generate is B Nimplies A

That's it, now you have your borrows. For your second half adders it's simply a matter of XORing the borrows and output from first half subtractors together as we have concluded beforehand.

I have built it and this is the result, I made it into an ALU pretty easily. Only thing with this particular design is I made the OR be B Nimplies A instead. Not really necessary, but my first XOR was based on 2 Nimplies gates OR'd together so it was easier to make it as such

My subtractor is however poorly optimized and slow, it acts for the most part as a proof of concept. I haven't bothered to count how long a calculation might take, but if I have to guess, it's prboably 5-7 ticks. Yes, it's also non-synced. I believe however that I could easily boil that down to 4 ticks synced. I will definitely be looking into it, but for now, this is it. To get to this subtractor, you can do /warp BLE.

- Pablo

<-- The actual Minecraft server host