Beyond Hack: Hacked

[NotRandom]

This is mostly for discussion and not exactly to have any questions answered.

To me it seems like a proper Hack implementation would need to be built from actual gate chips. For example a 6 pin microchip could hold 2 AND/OR gates (A, B, OUT). I'm beginning with FPGA to have a hardware implementation, but there are certain differences that don't make complete sense. The synthesis from Verilog is built with LUTs, so even a direct translation isn't the same. It is interesting to see that my adder circuit built in the hardware simulator is exactly the same as "x + y" from synthesis though.

To my main amazement, is with the Arty S7 FPGA board. This is mainly brainstorming, but it seems like the Spartan-7 chip would be able to hold 120 Hack cores. In the sense that it practically has 120 built in Hack ALUs as DSP slices. It also has enough block RAM that it should be able to even run 120 (maybe 60, not completely sure) Hack systems separately, just from being able to all fit.

Then of course there is the idea of building and experimenting with completely made up architectures. The Hack ALU is still mysterious to me, which I like to keep it that way in a certain sense.

[WBahn]

How is your 6-pin microchip going to hold 2 AND/OR gates? Do the gates share the same input so that you have one pin that is the AND of 'a' and 'b' and another pin that is the OR of those same two signals?

Don't forget that your microchip needs power and ground, too.

Most physical implementations of the Hack are done via an FPGA. Trying to do it with discrete gates would be an enormous undertaking. The complexity is roughly comparable to the original PDP-11, which cost $20,000 in 1971 (about $160k today).

FPGA synthesis is almost entirely LUT-based, but that's a detail that the designer (largely) can remain blissfully unaware of.

Bear in mind that the Hack computer in Nand-2-Tetris is not truly a complete computer. The student does not implement the ROM or the means by which to load a program into it. The student also does not implement the I/O functionality that looks at the SCREEN memory and drives the display or that puts the keycode from the keyboard into the KBD memory location.

You really should make the effort to own the Hack ALU in terms of fully understanding how it works.

There are only 18 defined instructions, so walking through each one and following the x and y input through to the output doesn't take too long. Most of them shouldn't present any trouble. Those that you are struggling with, we can discuss them.

The whole point of N2T is to take the mystery out of what a computer is and how it works.

[NotRandom]

I didn't think about having a power to the gate microchips, I was just thinking the signals themselves would power it. Considering actually building a NAND machine though it makes sense.

Using the PDP-11 as an example thought experiment, I can also buy an 8080 CPU for $1 (maybe less in bulk), but in the 80's it was more like hundreds.

To me the Hack computer and course equips any student to be able to continue on and build a fully complete computer by following out any logical reasoning learned from the project.

And my main concern with the ALU being mysterious is all the undocumented functions and what exactly brought the design about. Being blissfully unaware of programming it in Verilog is definitely not the same.

[WBahn]

While the cost of a CPU has dropped dramatically (on a per-gate basis), the cost of individual gate chips really haven't because the cost is dictated more by the package than the silicon. The original PDP-11/20 was built with 7400-series logic chips and the CPU occupied five good size printed circuit boards. That would still cost a lot to implement today and the Hack is going to be comparable.

The project doesn't quite equip students to build a fully complete computer, but it gives them a very good start in that direction. The implementation of the memory-mapped I/O devices is not trivial and is well beyond the scope of the book.

The undocumented functions are pretty easy to map out and there are some that are potentially useful. There are also several ways of doing the same operation, so while six control inputs implies 64 operations, the actual number is considerably less.

[NotRandom]

Thanks, I think that answers anything I could have been wondering, at least in scope of Hack. I definitely don't know how to start going with multiple cores yet.

To add to the implementation idea, I think an emulator in a micro controller would even be doable. Which kind of goes with an 'authentic' Hack vs. 'unauthentic' Hack depending on how the ALU is implemented. Specifically with several ways of doing the same operation. If it's built only to address documented operations, the machine code could be modified and break any 'unauthentic' implementation. The 'authentic' one would have no difference.

I've tested this in the hardware simulator. It works like an authentic simulator should, but it doesn't know what to call the undocumented functions.

[WBahn]

The hardware simulator doesn't know anything about documented or undocumented instructions -- it is simply simulating the various parts as they are connected in the .hdl files.

The CPU Emulator, on the other hand, only attempts to faithfully implement the 28 defined mnemonics. If you provide it with a machine code file (i.e., a .hack file) having C-type instructions that do not correspond to the ISA, the behavior is not well-defined at all. A few of them do what they should as if the ALU were implemented as implied, but most do not.

[dolomiti7]

Some time ago I created a table with all possible ALU calculations on the Hack platform. I came up with 32 possible operations (the other 32 are just aliases of existing functions).

On top of the 18 defined instructions there are 14 possible calculations which might be useful for some special cases (if supported by the hardware AND the toolchain):

x NAND y
x NOR y (both obvious, just AND/OR with inverted result)

        x AND !y  (this could be helpful for a XOR -> (x&!y) | (!x&y) )
                             ;ALU zx/nx/zy/ny/f/no=000100
NOT (x AND !y)
        !x AND y   (2nd part of XOR)
NOT (!x AND y)

Various arithmetic:
-x-y-1
x-y-1
y-x-1
-x-y-2
x+y+1
-x-2
-y-2
-2     ;ALU 111110

I just included the ALU opcodes for 2 of the calculations, but it is not hard to figure out the other combinations.

[WBahn]

Yep. Depending on which course I'm folding part of N2T into, one of the assignments is for the students to map out the entire functionality of the ALU. Part of the difficulty they run into (because I don't give them a specific heads up, even though I allude to it in lecture) is that they have to decide whether to express the functionality in arithmetic or logical terms.

For the assembler, I usually just require that they add support for X codes, in which the mnemonic Xhh replaces the hh with the two digit hex representation of the 7-bit comp field.

The problem with following down this path is that the CPU emulator does not faithfully implement the entire ALU behavior, so I either have to abandon this path at this point (and, for some courses, this is adequate to make the point) or supply them with a CPU emulator that does support them. An other alternative, which has not been applicable for the courses I've used N2T pieces/parts in, is to have them write a suitable emulator.