There is something I have been working on for several years (on and off) which I feel is probably now as polished as it is likely to be that I wanted to share with the community.
My problem thesis is that I always found if you are unwilling to simply cave and use the provided course implementations when moving from one level of abstraction to the next (which is totally sane for the sake of time / typical student experience) is that it is difficult to backtrace any bugs below the current level. If your hardware has bugs, debugging assembly is not fun. If your compiler has bugs, debugging Jack is not fun and so on. How, I wondered, were the original authors able to make their own implementations so reliable with the relatively sparse level of testing on hand.
Enabling the tools to run headless was a good start, many lacked features that I wanted or would still require significant scripting to automate everything that I wanted to do. I tried looking at the tool implementations but not being a Java dev myself I found them too opaque with too many layers of abstraction hiding the actual implementation details.
"Fine, I will do it myself. How hard could it be?"
5+ years later:
https://github.com/c0ff33-dev/nand2tetrisSome cool features:
* Pygame frontend that mimics the interactive functionality of CPUEmulator for HACK assembly:
* Gdb-like interactive debugger for HACK assembly that correlates instructions to the actual lines in the source file (for comments etc), source line & symbolic breakpoints, context sensitive highlighting for when registers change and when JMP conditions are met, call tree and stack tracing, arbitrary memory peeking:
* Simple CLI to run all available tests with a global config to enable or disable the parts that you are still working on or have not yet implemented. This part is probably still a bit tightly coupled to my own implementation.
* Added ASSERT directives that allow runtime assertions for RAM values and whether the code is reachable. These are implemented as comments in Jack which are compiled down and interpretered at the assembly level by the engine. Unprocessed assertions will trigger a runtime error in the event that control flow has broken somehow during emulation.
* Used the toolchain to support development of a real FPGA project:
http://nand2tetris-questions-and-answers-forum.52.s1.nabble.com/I-heard-we-re-posting-FPGA-builds-td4038627.html (
https://github.com/c0ff33-dev/nand2tetris-fpga).
* The compiler is also fairly sophisticated with instruction perfect reproduction of the course compiler output at the VM level. It compiles the original Pong program down to ~27k lines and the resulting binary will also run on the original CPUEmulator. I had so many linker related problems in my FPGA project that eventually I resolved to make it quite strict about being able to identify unlinked & uninitialized libraries, type checking & as a minor optimization it will also automatically prune dead/unused code at the library level. I don't think I explicitly check all the things the course compiler does but it will promptly error out if anything escapes the expected bounds, probably there are still bugs in Jack patterns I haven't yet seen.
* Finally the Jack OS implementation is based on a (manual) decompilation of the course provided VM libraries but like with all reverse engineering it may be an imperfect reproduction in some cases where I had to infer types or author intent.
Nand2tetris has been an epic journey and one of the most memorable projects in my life so I just wanted to offer my deepest thanks & gratitude to the many authors and contributors who inspired me along the way.
Thanks for reading if you made it this far :)
Locked
