The current implementation of memory for simulation is unrealistic in that it provides "immediate" access to data; as soon as the address is applied to the input, the content word can be read from the output as if there were no inherent latency.

Part of the rationale for making memory a separate component for simulation is that real chips tend to use a higher-density technology for memory, so simulating a memory built from logic gates is silly. But to keep some level of realism, we shouldn't actually let chip designers treat the memory like a register that you can access within a single cycle. The latency of accessing memory should be a design constraint (i.e. if you want to make your chip go faster by having more accessible data, you have to add gates for registers, you can't cheat by treating the memory like a magic cache that provides sub-cycle access.)

In fact, most of the designs implicitly tolerate one-cycle memory latency; they're designed to do address calculation with one instruction and then consume the value from memory with the next. But the simulator doesn't model that behavior and some of the alternative designs I've added are probably playing fast and loose. In particular, I have a non-pipelined RiSC-16 implementation which uses this cheat (or I think it does; it would be great if the simulation proved it.)

Requirements:

• RAM updates its output only on the cycle after a (new) address is presented
• Accept a new address in each cycle, so throughput is still one word per cycle, just with a delay/latch
• Document/test that behavior so solutions are still consistent with the discrete component

What, if anything, does this mean for writes? If there's write delay, can it be observed? It's OK to set the address, the input word, and the load bit all in the same cycle. If you then unset load and try to read the same word, that would be subject to the normal read delay, right?

Hello Moss Prescott,

A really nice project!

Sometime ago when I was starting to do Nand2Tetris I really like the project but I didn't like the Java tools, they didn't resonate with me.

And at the time I would like to know How I could build all the project in Rust from the simple gates without using there hardware emulator, doing all from start to finish.

But then I come to the conclusion that a logic simulator that can simulate feedback loops isn't as easy at it sounds and the thing stayed that way. Without me doing the simulator in Rust. Only the first steps in Nand2Tetris, but like I said I didn't liked the tools.

Then I tkinkered mentally with the idea of simulating the NAND circuit electrically by simulating the transistors mathematically, even if it was only one logical gate in all the project.

Like allowing the simulation of at least one peace at each level.

And why staying at that level and not learning how to simulate one transistor at a atomic/quantum level? heheheheh It would be really fun to learn all the things about it! And to have at least one component that would work that way.

Then I toyed mentally with the idea that the NAND circuit for a NAND can be made with two transistors one nmos and one pmos and that all the processing of all NAND gates could be made to pass over that two real transistors. With just a control unit made with a Raspberry Pi Pico and the processing of a NAND chopped up into peaces. In with you inject a 3.3V one or a 0V zero and after a delay or instantly you would receive the result of the transistor processing, as a logical value or even as Voltage ADC value.

But currently I'm just interested in knowing what's the license of PyNand to know if it's possible to reimplement it by some kind of translation from Python to Rust.

Thank you for the really good project!

The very best wishes,
João Nuno Carvalho

There are three obvious sub-graphs whose results are not used a lot of the time:

• The entire ALU result is unused on every @ instruction, which is 9.5k out of 27.5k (35%).
• Only one of the + and & ALU ops is ever used.
• The JMP condition is unused unless not an @ and one of the three bits is set.

I tried converting each of these into if instr & 0x8000: by hand, and got ~25% speedup overall.

To automate that would involve analyzing the node graph to determine what parts of the graph need to be evaluated when. Something like: "what subgraphs are referenced only on one side of a conditional (i.e. Mux16), and what is the condition?" but it's tricky because the ALU output is referenced many times, with various conditions, all of which include the same bit of the instruction in some way.

Turns out CS is hard.

Currently, parse errors come with a source location in the form of a token index:

Expected token ('symbol', ';') at location 4281; next token: ('keyword', 'let')

But there's no practical way to map that index onto a line number and source file, which is what would actually be useful.

What you want is something like:

Parse error at Foo.jack:1110; expected ';':
        let ptr[0] = x
        let ptr[1] = y;
        ^^^

Note: we can't easily enhance the parser to know about raw source locations because the tests for project_10.py require a lexer that produces tuples which are just (type, string).

When writing any kind of non-trivial Jack code, the complete lack of any type checking means both wasting time fixing silly errors and adding types that are effectively never used (except as documentation).

A simple type-checker would catch a lot of the simplest problems, although the language and its types are pretty weak.

Motivating example: the Scheme interpreter needs to convert between tagged values (typed as Obj) and pointers (Rib) before using them. These conversion are all over the code, which is fairly complex to begin with, and it's very easy to miss one. On the other hand, the interpreter also indexes directly into ribs to avoid the overhead of method calls, which will produce unhelpful type errors. Arguably, the fix for that is inlining the methods.