Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
If you want to share, help etc. you can visit discord (link is at the games main menu) - there is a dedicated channel for highscore-hunting
The downside is the game calculates score as gates + delay + ticks, prioritising low gate solutions over fast solutions.. Which is... well... hmm....
A great example of why delay and ticks should receive a larger weighting is the level "adding bytes". The level comes with an an achievement for being less than 35 delay, and the best your going to achieve mixing full adders / half adders and building a fast carry chain is 36 delay . HOWEVER he says going into spoiler mode if you build a CLA (carry lookahead adder) along with a CLU (carry lookahead unit) wikipedia links for both are https://en.wikipedia.org/wiki/Carry-lookahead_adder and https://en.wikipedia.org/wiki/Lookahead_carry_unit I should probably link these 2 wikipedia articles to help with the math https://en.wikipedia.org/wiki/Logical_disjunction https://en.wikipedia.org/wiki/Logical_conjunction you can achieve some pretty low delays the Wikipedia articles imply a 12 delay is the limit BUT due to the gate count, the game will consider these solutions inferior. So whilst you popped the achievement, the game will use your slower answer (unless you reset the save, and build again!).
In the spirit of your post...
counter: 53 gates 20 delay
Equality 31 gates 14 delay (your score has me re-looking at my XOR OR NOR reduction).... 31 gate 10 delay ( 3 input OR gates are not your friend).
full adder: 9 gates 8 delay (I believe this is optimal, replace your XOR gate achievement solution with the standard 3 gate solution!)
signed negator: 27 gates 16 delay (I think this is optimal)
Adding bytes: 90 gates 12 delay (see spoilers for how!)
Your 2 XOR scores are not interesting... XOR == (A OR B) AND (A NAND B) with XNOR == (A OR B) NAND (A NAND B), as both AND and NAND have gate score 1 instead of the NOT version having score 2, well an easy optimisation (when high score chasing) is to delete the NOT gate and use the NOT logic version.
"Delicious Order" Gate 2298 delay 62 ticks 31
This super annoys me about the games score weighting.
Using domain knowledge I can reduce ticks down to 30, at the cost of a few logic gates (except the logic cost overwhelms the reduced tick cost). I can use some more domain knowledge to get the the ticks down to 29, but the logic cost kills the score.
The bottom line theres no incentive to make the solution 124 time units faster, as it would just drop me down the leaderboard.
Byte of parallel XOR make Propagate
Byte of parallel NOT make /Propagate (NXOR instead of NOT might save a count)
Byte of series Switches pass Carry through like a wire (only if Propagates are true)
Byte of parallel AND make Generate/Annihilate
Byte of parallel Switches pass Generate/Annihilate (only where Propagate isn't true)
Generate/Annihilate merges with the Carry chain to replace what didn't Propagate.
Byte of Parallel XOR invert each output (wherever Manchester found a Carry)
I don't yet know the propagation delay of Turing's simulated switch gate? In real ALU I've built (not just for ADD), 74CBT3253 twin MUX4 switch in 6nS, but propagation delay through prefixed switches is only 250pS RC per spec sheet. Not accounting for Elmore, fanout of eight XOR gate inputs, and final Carry that Manchester Carry Chain must drive.
Steam awarded "fast adder", but doesn't say by what margin I beat the clock. Screenshot can be found on my profile page, not quite sure how to attach it.
Point is that XOR/NXOR throw all switches at once. After prefix, a maze of closed switches is just wire. Carry's passage through or replacement along the way is not determined by Carry, thus ripple is avoided.
-edit-
I've since done better by deconstructing XOR into simpler gates to expose
free AND for Generate. Reassembling with differential OR NOR outputs.
72 gates, 22 delay. No unrealistic OR cheats, though switch gates seem
to ripple through as buffers rather than wire. Should be prefixed switching
all at once with 2 delay, then passive throughput. But not how they score.
The leaderboard for adding is dominated by XOR gates with 2/2 score.
Only seeing the scores, not sure how that was done, but whatever...
-edit-
64/22 abusing self-controlled switch as a diode. Not quite free, but still
cheaty, as diode OR relies upon an unrealistic open pull-down. Switches
go tri-state when switched OFF, but drive LOW when ON given an open
input. Buffer'd tri-state rather than transmission gate behavior.
We probably need both kind of switches. Also pull-ups and pull-downs.
Open outputs should be allowed, but open inputs should flag an Error.
Weigthing is not enough. Consider a register file. My solution requires 4 gates per bit and a shared NOT gate, with a delay of 4. An 8-bit register thus requires 33 gates with 1 output or 41 gates with 2 outputs, and a register file with 8 registers takes 264 gates (excluding address decoding). But the delay stays 4. No matter how much weighting you apply, more complicated solutions will end up preferring a gate-based optimization.
I suspect a better score would be by multiplying gates, delay, and cycles, rather than adding them. Or have separate leaderboards like in the Zachtronics games.
There is also the consideration that needs vary. You may want to use a carry lookahead adder in your ALU, because it is in the critical path, while using a ripple-carry adder in the program counter increment unit to save gates. Though in that last case a dedicated increment unit would be even more efficient than a standard adder.
Checked out the `.win` site linked above, it does have seperate leaderboards. It just defaults to sum.
Equality: 31 gates, 10 delay
Full adder: 7 gates, 8 delay - (Hint: build XORs from other gates instead using single-component ones)
Adding bytes: 154 gates, 24 delay - Someone earlier hinted how.
Signed negator: 30 gates, 10 delay - (Hint: If you did "Counter" well, you know how to do this.)
Xor gate : 3 gates, 4 delay - although, outside the game the version with 4 NAND gates is better
Xnor gate : 3 gates, 4 delay - similar concerns as for XOR
3 bit decoder: 14 gates, 6 delay - I'm quite proud of that but I don't know how to give a meaningfull hint without pasting a screenshot of the solution. Just stare at it and at the De Morgan's laws until you start to see patterns. (Btw, the leaderboard says someone finished this with delay 2, which I'm 99.9999% sure mean they were cheating. I don't think the leaderboard actually verifies these solutions on server side.)
Half adder: 3 gates, 4 delay - (Hint: be clever with how you build the XOR gate)
Counting signals: 13 gates, 8 delay - (Hint: I made it almost entirely out of half adders)
Counter: 51 gates, 10 delay (total 61). replace 8-bits INC with two 4-bits INC (bit 4 does not use Carry from bit 3) in order to optimize the delay. the additional cost of the higher 4 bits is MUX.
"The product of nibbles" gate cost 101, delay 48, for a score of 149.
Sure there are faster solutions,and I can see some optimisations, but as a solution it defines the term "wire spaghetti is beautiful!". And oh boy is it wire spaghetti.
3 distinct multiplexors designs:
1 x 0:4
1 x 3:5
2 x 4:5
Oh and the 2nd 4:5 multiplexor is split into both a horizontal and vertical section!!.
2 distinct 4 bit adder designs:
1 x half - full - full - half
2 x half - full - full - full
It uses the XOR is a half adder trick you can build a 3 component XOR gate using a NOR + AND gate as the first section and feeding their outputs into a NOR gate. This allows you to tap off from the AND gate to get the carry
And finally the wire spaghetti, building all of this without access to the custom components, ends up with a horseshoe layout where half the circuit travels from the bottom left towards the top, before having to move to travelling down the right. The ""tidy"" transition is just heartwarming. Sure I can see some optimisations in my multiplexor designs, but why would I want to destroy such neatness
https://steamuserimages-a.akamaihd.net/ugc/2506886431718136565/B5AF335D8BAE9960E93E0CF051062F6E6A9FF0FA/?imw=5000&imh=5000&ima=fit&impolicy=Letterbox&imcolor=%23000000&letterbox=false
Could you maybe upload this picture zoomed in more? I can't see which gate is which.
I could provide some optimisation hint if I see it. (Mine is 84 gates, 48 delay.)
However, this is not my favorite implementation of the product of nibbles. I made one that has 12 delay (and 2362 gate score). It doesn't make for a very good overal score but I suspect that real processors may utilize something like this, at least for partial results.
Screenshot: https://steamcommunity.com/sharedfiles/filedetails/?id=3003822130
I suspect this reply may raise more questions than it answers.
The original was based on the following pseudocode:
total = 0
for i in range(bits)
if B & 1
total += A
B >> 1
A << 1
Which is the usual algorithm for doing multiplication on hardware without a mult opcode (think oldskool 6502's). Converting that to hardware creates 2 execution paths, hence the need for 3 multiplexors to simulate the IF.
The obvious optimisation, if we have to carry the cost of the add in each step is therefore...
total = 0
for i in range(bits)
total += B & 1 ? A : 0
B >> 1
A << 1
Which instantly negates the need for the multiplexors, saves 17 gates, and doesn't look as messy. Resolving to 84 gates 42 delay. Let me know if you'd like me to upload it to the component hub so you can play around with it.
Nah, I think I can now imagine what you did, especially that I'm pretty sure that after these optimizations you've mentioned, you'd land on the exact same design I have (except the spaghetti bit), so I have this as a reference.