Disable gate and delay score calculations

[D. Wolfin]

I am playing around with manual ram design using abstraction. For instance, I created a custom 64 byte ram register using D Flip Flops, then began combining them in groups of four, adding an additional 2 bits to the address each time.

i.e ({addr bits : bytes of ram} > {6 : 64} > {8 : 256} > {10 : 1K} > {12 : 4K} > {14 : 16K})

The issue is the gate score is increasing exponentially and the game has to recalculate this with every adjustment (including each subsequent inner component) and while trying to create the 16kb component, the entire game is crashing as a result. For reference, the gate score for a single 4Kb ram unit is 217,278.

I had wanted to scale up to 256Mb at least, but that is not possible doing it manually.

Is there a way to disable the gate/delay calculations?

[MegaIng]

How do you know it's specifically the score calculation?

The game needs to create a single DAG with all custom components inlined, just for simulating them, score calculation is hust a trivial extra step.

Just don't do what you are doing. Use the builtin RAM components. This is not, and (probably) never will be, a supported way of designing circuits.

[D. Wolfin]

Perhaps it could be just simulating so many gates is impractical, straining the game until it crashes, and score calculation is trivial in comparison as you say, but I can only guess based on what I can see. If I could turn it off with a command and have it not recheck with every update to a wire or component added, I would be more certain whether this affects it or not.

The only way I could actually test this is by disabling it and seeing the changes, hence the question.

This is not about designing a functional computer. I wanted to learn more about RAM and how it functions, so I am learning by designing. Simply telling people not to do that, because you just don't do things this way, is not what I would consider positive or constructive.

[MegaIng]

With my knowledge about the game's internals, based on discussions with the dev and having seeing the sourcecode, and since you don't have any particular reason for thinking it's the score calculation, I am going to once again say: Yes, the score calculation is trivial, the problem is creating such a huge graph. If you don't want to believe me, that's fine.

Each individual builtin component, each wire, each IO pin all take up a single node in the graph. Each individual node takes a fixed amount of memory (more than 200 bytes), plus any extra state that needs to be stored (the wire value, the value of the register, the values of pins), with those data values only being multiples of 64bit words. Yes, this is a lot of unnecessary data, and the next engine update will reduce this, at least while executing.

The gate and delay scores habe basically no relation with actual execution complexity. If you want to get an idea of the current size and therefore cost of your schematic, use the `export_dag` command in the console (https://github.com/Turing-Complete-Game/Suggestions-and-Issues/wiki/Debug-Console-Commands)

[D. Wolfin]

What are you talking about, I never said I don't believe you. I even said you may be right, but you asked me about why I believed it was caused by the gate score calculation. I hold no reason to not believe you in that its caused by the DAG, as that is more than reasonable. If you consider the graph there is 1@4kb comp * 4@1kb comp * 4@256b comp * 4@64b comp * 64@1b comp * 8@1bit comp, or 4*4*4*64*8=32768 schematics (times however many IO pins etc) being linked together.

I could not test my hypothesis, so my question was if there was a console command to turn off this feature which would have either remedied my issue, or shown it was something else. Perhaps I should have said "I believe" before "The issue is", but that is how it looked from the perspective of someone who hasn't seen the source code nor knows how the game functions internally.

In any event, the purpose has only been to:

a) learn more about RAM, and
b) create a large virtual RAM component to practice working with large address values and some basic op codes, and
c) try different methods of storing values into RAM and try create reliable variable word length values. Probably impractical as it would slow down the whole system, but it seems fun.

I would say 'a' has been mostly successful, I can create and use a 1kb RAM component pretty reliably.

Edit: The DAG file is approx 1,057,000 nodes for a 16kb RAM component with only 1*4kb comp in it (adding the second causes the game to crash). Abstraction at its finest.

[MegaIng]

Ok, an alterntive argument without using any knowlege about the games internals, maybe that can convince that testing your hypotheses would be pointless: Calculating the score of a schematic is strictly less or equal amounts of effort to running a single tick of simulation, obviously. Both need to look at all components*. Even if it was the score calculation that was the problem, that would mean you could also never run the simulation, making the circuit you are building pointless anyway.

*(Yes, technically, not all components have to be computed each tick. But then a preprocessing, i.e. compile step would be necessary to check which components are needed, which would definitely be more effort than score calculation).

For b and c: Use the builtin RAM components. That is what they are there for.