Stack-structure is for RAM but program counter only connected with ROM

[BigBang]

I completed the first part of nand2tetris (great experience btw) and now I take part 2.

I just don't understand one thing:
The stack in nand2tetris part 2 works on the RAM, but on the Hack-Computer itself, jumps can only be made in ROM because the RAM is not connected to the program counter.
Only the ROM ist connected to the program counter in Hack-PC.

How can I jump on the RAM in Hack-Computer?

[ivant]

First of all, the HACK platform doesn't know anything about the stack. The assembler has a name for certain RAM address, but that's as far as it goes.

In HACK, the jump address is in the A register. It could be loaded both from ROM and from RAM. (It could even be computed with a C-instruction.)

[BigBang]

Thanks for answer!

What I mean is a jump with condition with C-Instructions.

For instance:
@2
D+1; JGT

This is a jump in ROM.
If the jump-condition is false, than the program counter increased and the A-Register is ignored.

But whats about jump-instructions in RAM.
The @2 selects RAM[2] anyway.
So it doesn't matter if the JGT-condition is true or not. Seems like it's not a jump.
The RAM also have not a counter.

I don't get it. Can you explain it to me? Maybe you can give an example?

[ivant]

Ah, I understand now. No, you can't jump in RAM with HACK. In fact, hack can't execute instructions from RAM at all. The authors describe HACK as following the von Neumann architecture, but in fact it's closer to Harvard one.

You can still hold the address for the jump in RAM, which is what you need to implement the calling stack.

[BigBang]

Sorry again... and thank you for your previous replies!

Do I understand it correctly now:

The stack instructions with the jump-instructions are not written to RAM in real time, but must have been previously stored in a program.
So the Hack-Computer is not designed for me to write a program with jump commands in a console,
rather, the program must have already been written (e.g. on seperate computer with a compiler) and compiled beforehand and be available as binary data in ROM.

The ROM program then uses only the RAM for the stack model to store data for the current run of the program.
So the stack model has already been implemented in the program, not in Hack-Computer.
The reason we use the stack model for programs is because it helps us compile and run a high-level language like Jack and for a clear program control.

[ivant]

I think I confused you a bit here, because I thought you were asking specifically how the call-stack would work in HACK machine code.

The stack-machine as described in the course, is an intermediate representation. The idea is that translating from a high-level language, such as Jack (the language that is implemented in the second part of the course) directly to hack machine code is hard. Instead we build intermediate steps to help us in the process. The first one is the HACK assembly language, which is very close to the machine language, but is easier to read and write.

The next level is the Stack VM. The VM's language is similar to, but also higher level than the HACK assembly language. We create a translator from vm -> hack. You can read this thread if you are confused what virtual machine means in this context.

The next part creating a compiler for a high-level language called Jack. So in essence you write a program in Jack, which is then compiled to .vm, which is translated to .asm, which is assembled to executable file. All these steps happen on your actual computer.

The final file can be loaded in the ROM memory of HACK and executed. This is similar to a cartridge-based game consoles.

[BigBang]

Thanks. I think I got it now!