I'm well-aware that a 3-tick full adder has been built before, but I just designed a version and thought I'd share it (especially considering how few have been built). The basic idea is to have the c-out feed directly into the carry line. The XOR I used is anomalouscobra's design, which happens to be what makes building this possible (he was also the first to build one).
8 bits:
My half-adder design (keep in mind that to stack these you need to do some staggering):
In the world save I have some note blocks set up to monitor the speed, one thing to note is that that there's an extra repeater on both sides of the test lever, so it is in fact three ticks. :smile.gif:
Edit: I updated it so that the upper input is a true input.
Cheers thanks for clearing that up. From the picture thats what I expected considering there was 8-bits gotta be done in binary. Looks pretty cool how you have done this, even if its been done before. Good job buddy! :wink.gif:
You showed me this design on the RDF, but I didn't have time then to give you a full critique, so here goes:
1: It is not a 3-tick adder.
This is a fairly major point. It's true that a change in the lower-input (changing "11111111 + 00000000" to "11111111 + 00000001") results in a Carry-Out after 3 ticks, this is not actually reflective of the speed of the device in general operations. It's a demonstration of the power of the "Instant-Carry" technique pioneered by Ohmganesha, but not functionality of the rest of the device.
It's understandable that you were trying to measure the slowest operation of the device to judge its speed by, but unfortunately, you accidentally picked it's FASTEST operation!
The tests that would have been more indicative of its true speed are:
-Bit Throughput, where you measure the time it takes a change from input A1 or B1 to be seen at output O1. Note that you will get different values for A1 (upper input) and B1 (lower input), and that you will get different speeds for 1->0 and 0->1 due to the fact that piston-retraction is instant, but extension is not.
-Bit Throughput with Carry, where you do basically the same thing, except you're looking for changes on output O2 (or O3 or higher) resulting from changes to A1 or B1.
2: Un-necessary Torches
Since you didn't know that you can make a full-adder using XNOR gates, it is understandable that you modified Anomalous Cobra's XNOR gate into an XOR by adding a torch to the upper input. This unfortunately added extra delay to the upper input of your XOR gates, which resulted in a total of +2 extra delay over-all. Still more unfortunately, your speed-test didn't measure this pathway, since it seemed to focus almost exclusively on the "carry" operation.
Making a Full-Adder with XNORs instead of XORs is actually shockingly simple. XNORs substitute perfectly for XORs with only one exception: The value you use to determine whether the "Carry-In" travels on to become the "Carry-Out" is simply the inverse of what you'd get with XORs. There's really no other difference. If the output from the first half-adder is a 1, then you block the propagation of the "Carry-In". If it's a 0, then you allow it. Just shift your the piston you're using for the "Carry Control" by one block and its behavior will be inverted. All done!
3: Use of directly anchored levers as inputs.
The way your upper input is designed is problematic, since the AND-gate is only getting a signal because there is a lever anchored to the block above its wire, making that block "Emit" redstone charge. If your device were to receive its input from a normal redstone wire instead, then its AND-gate would be completely non-functional, unless you were to use a repeater that pointed into the block that the un-necessary torch is anchored to.
This is a potentially dangerous mistake, because it means that what seems like simply an interchangeable data input is in reality an integral part of the device, and the only way to retain that functionality is to use a Repeater which adds a delay. Using a lever in such a fashion can hide an extra delay in your machine.
Conclusion:
The device which you have pictured here has, by my estimates, has a real delay of about 6 ticks (not the 3 advertised) due to some errors in design. I don't mean to be overly harsh in my criticism, but the fact remains that it doesn't do what it says. However, in the area of "Operational Speed", I have seen almost no devices which actually do what their creators claim they do, so I'm not singling you out here.
I'll give you what knowledge I have about the construction of fast adders when next we meet.
Hans Lemurson's Thread of Links:http://www.minecraftforum.net/topic/371610-hans-lemursons-thread-of-links/
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.
8 bits:
My half-adder design (keep in mind that to stack these you need to do some staggering):
World Save
In the world save I have some note blocks set up to monitor the speed, one thing to note is that that there's an extra repeater on both sides of the test lever, so it is in fact three ticks. :smile.gif:
Edit: I updated it so that the upper input is a true input.
I am a bit new with redwire but I am picking it up real quick due to being an electrical engi student :smile.gif:
http://www.youtube.com/user/StephennJF
it's a binary adder, duh. there are tons of these, some less, and some more compact. some faster , some slower. although this is a very good design.
is there a download?
Adder
Also, just in case I wasn't clear in the first post this adder is 3 ticks for the first 8 bits and 1 tick for every additional 8 bits.
Edit: I'll put together a world save. :smile.gif:
http://www.youtube.com/user/StephennJF
Was that necessary?
1: It is not a 3-tick adder.
This is a fairly major point. It's true that a change in the lower-input (changing "11111111 + 00000000" to "11111111 + 00000001") results in a Carry-Out after 3 ticks, this is not actually reflective of the speed of the device in general operations. It's a demonstration of the power of the "Instant-Carry" technique pioneered by Ohmganesha, but not functionality of the rest of the device.
It's understandable that you were trying to measure the slowest operation of the device to judge its speed by, but unfortunately, you accidentally picked it's FASTEST operation!
The tests that would have been more indicative of its true speed are:
-Bit Throughput, where you measure the time it takes a change from input A1 or B1 to be seen at output O1. Note that you will get different values for A1 (upper input) and B1 (lower input), and that you will get different speeds for 1->0 and 0->1 due to the fact that piston-retraction is instant, but extension is not.
-Bit Throughput with Carry, where you do basically the same thing, except you're looking for changes on output O2 (or O3 or higher) resulting from changes to A1 or B1.
2: Un-necessary Torches
Since you didn't know that you can make a full-adder using XNOR gates, it is understandable that you modified Anomalous Cobra's XNOR gate into an XOR by adding a torch to the upper input. This unfortunately added extra delay to the upper input of your XOR gates, which resulted in a total of +2 extra delay over-all. Still more unfortunately, your speed-test didn't measure this pathway, since it seemed to focus almost exclusively on the "carry" operation.
Making a Full-Adder with XNORs instead of XORs is actually shockingly simple. XNORs substitute perfectly for XORs with only one exception: The value you use to determine whether the "Carry-In" travels on to become the "Carry-Out" is simply the inverse of what you'd get with XORs. There's really no other difference. If the output from the first half-adder is a 1, then you block the propagation of the "Carry-In". If it's a 0, then you allow it. Just shift your the piston you're using for the "Carry Control" by one block and its behavior will be inverted. All done!
3: Use of directly anchored levers as inputs.
The way your upper input is designed is problematic, since the AND-gate is only getting a signal because there is a lever anchored to the block above its wire, making that block "Emit" redstone charge. If your device were to receive its input from a normal redstone wire instead, then its AND-gate would be completely non-functional, unless you were to use a repeater that pointed into the block that the un-necessary torch is anchored to.
This is a potentially dangerous mistake, because it means that what seems like simply an interchangeable data input is in reality an integral part of the device, and the only way to retain that functionality is to use a Repeater which adds a delay. Using a lever in such a fashion can hide an extra delay in your machine.
Conclusion:
The device which you have pictured here has, by my estimates, has a real delay of about 6 ticks (not the 3 advertised) due to some errors in design. I don't mean to be overly harsh in my criticism, but the fact remains that it doesn't do what it says. However, in the area of "Operational Speed", I have seen almost no devices which actually do what their creators claim they do, so I'm not singling you out here.
I'll give you what knowledge I have about the construction of fast adders when next we meet.
Look here to find links to my inventions, creations, and my Youtube channel featuring Amazing Creations of Mine (Redstone engineering FTW!!!) and charming Music-Videos about clones. I also made "Minecraft in Minecraft" (2D platformer/building game). I'm currently trying to make a computer.