Advanced Redstone Computer Tutorial ?: ALU - Flood Carry and Invert A/B

In this video we add optional inversion for input A/input B as well as a method of flooding the carry in order to invert the output.

[vinigretzky]

You said yourself that you did research for 2 months to come up with such a fast and clever design (I mean the way you used piston mechanics and the fact that it's so small is just outstanding). All that effort is now obsolete in 1.5 because you can just use an instant ALU in an anti-burnout CPU to get a clock speed of 5 Hz.

[bennyscube]

It's more than I can explain in a post, but here's the just.
If you're going full on instant everything, then the most significant drawback will simply be size.
If you're not, then you'll be using a pipeline, which achieves the same clock speed in less space. The issue is the program can access data before it's computed, and branching can cause some instructions after the branch to execute before the branch is performed.

I'll explain more in the video, but hopefully this gives you an idea.

[SebAndNick]

Well the really amazing register that I was going to use is insanely fast, and takes the inverted inputs into the D Flop. I'll have to show you on the RDF.

[vinigretzky]

You are completely right about this, I was just concerned that I am missing a function in my instant ALU where inverting A AND B (I don't mean the logical function :D) would take up too much space and increase the lag. Since nobody on the RDF forums is answering me, could you give me some tips where I should put a comparator in the ALU (at the end or after the first XNORs)?

[SebAndNick]

You can easily make the XNOR for the inputs NOT reliant on the control bit at all. Granted, it will make the XNOR a bit slower.

[bennyscube]

Oh absolutely you could yes. However, what's the advantage of that other than inconveniencing the programmer? It adds no delay and takes up very little if any extra space.

[bennyscube]

I'm sorry, what are you disagreeing with? I think I misspoke, because I wasn't stating an opinion, or at least I wasn't trying to. I was referring to space-time tradeoff and pipeline hazards, which are both known drawbacks to a system like that. They shouldn't be significant issues in an ALU, but they can cause some strange behavior in a full scale processor.

By the way, your ALU sounds pretty cool! I'd love to see it sometime, it seems quite interesting :)

[ChartreuseKitsune]

Another method to have done the flood carry would have been to use torches to power up below the carry lines and power it from an inverse signal.

[bennyscube]

Not quite actually, there's a trade off with any change that supposedly improves the computer. In your example, the overall design would need to be massive, and the complexity of the system would make it likely to fail and immensely difficult to utilize all the potential performance. I'll talk about trade offs in a few more videos, but for now be aware that there's quite a downside to a system like that or really any system which makes heavy changes to improve theoretical performance.

[vinigretzky]

That last part let me a little bit confused because you don't have to do more pipelining than in the CPU you are building in this tutorial. And as I said, only the ALU is instant to get 5 Hz without lag.
Anyway, I am seeing forward to the video.

[bennyscube]

They don't "rely" on the control bit. I suggest going back and listening to the explanation of why it's there again. It's purpose isn't to make the adder faster, that's simply a side effect.

[vinigretzky]

I would really like to know how these negative side effects are going to come into play.
For now I just don't understand what would make it so much more complex and difficult to handle.
I wanted to make a video of the ALU or the small prototype 5 Hz CPU when the fatal piston bug is fixed. Or we skype and you join my server sometime.

[SebAndNick]

BENNY use Glowstone one block up from your flood carry line. That way you don't need repeaters to stop the back-flow.

[bennyscube]

What's the advantage of inverting the output of addition?

[SebAndNick]

The only thing I do not enjoy particularly about how you built the ALU, is the reliance on cut carry that you have created. (And partially the control bit). If either of those things derp, you will lose most all of your functions.

[bennyscube]

I'm sorry, I'm not sure exactly what part of the video you're referring to.

If it helps, that expression is the same as XOR.

[vinigretzky]

I don't really agree on that. I am currently testing my instant ALU with some repeater lock registers to calculate the fibonacci series and count up at 5 Hz. I still get around 400 FPS and the ALU can perform all logical functions, addition and subtraction. The only thing that causes problems (slows the clock speed down) is this piston glitch, where they pulse when they receive a 0 tick off signal but this should be fixed until 1.5.

[bennyscube]

I know, moving 2 blocks around and replacing fence gates with pistons is so difficult to do :P

[vinigretzky]

No I mean why do you need to be able to invert the A input AND the B input. If you have the logical operation a&!b you don't need !a&b because it just depends on the way you load the values you want to perform the function with into the registers.

[bennyscube]

Actually, I'm not sure that I do, could you elaborate?