Liberal use of temp

[kb-math]

So far I have - out of convenience - used the temp registers i.e., R5,R6, etc. liberally when implementing the "pop segment i" command to save temporary variables. I can see that I will probably use the same strategy in implementing the gt and lt commands (to overcome issues that have arisen in http://nand2tetris-questions-and-answers-forum.32033.n3.nabble.com/Implementations-of-gt-lt-and-eq-in-asm-td4032816.html). This means that a call like "pop argument 9" may edit the values in these temp registers.

Question: is this allowed? Or does our contract assume that a call to "pop argument 9" does not alter the contents of the temp registers?

For reference, here is my implementation of pop argument 9... notice the @R5 and @R6 lines which make use of temporary variables.

// pop argument 9

@SP
M=M-1
A=M
D=M
// save it for later in the temp, as we will need to put it in the right location in RAM
@R5
M=D

@2
D=M
@9
D=D+A
// So D is now the actual index of RAM where we want to place the value popped off the stack
@R6
M=D

// finally place the saved value
@R5
D=M
@R6
A=M
M=D

[kb-math]

Or perhaps instead of using R5 and R6, I can and should just use R13 and R14... as from browsing other discussions it seems these are free to use?

This raises an interesting question in general, if I have assembly code of the form

@newVar_i
M=i

for i=1,2,3.. then it will set RAM[i] = i or thereabouts (depending what else there is in between). This may corrupt the stack etc. if such new labels are created at inconvenient places? (e.g., if such @newVar_i lines are present in the asm implementations of VM_code commands like "lt" etc.)

[WBahn]

You are reading too much into the fact that one of the memory segments happens to be called "temp" and not "fred". Would you do what you describe using the memory space set aside for the "pointer" segment?

The temp memory segment is just that -- one of eight memory segments that can be written or read to using VM commands. The ONLY time that the values in that block of memory should be changed is in response to a

pop temp n

command.

Your VM implementation may, however, use R13 through R15 however it wants to. These are the ONLY memory locations that it is free to utilize for its own purposes because these are not within any of the eight memory segments (when the VM code is written as intended).

The "temp" memory segment is a place for code generated by the compiler to use for temporary needs, since the compiler can only generate VM commands. It's view is limited to the eight memory segments and it has no awareness of the physical memory layout of the actual hardware.

[WBahn]

kb-math wrote

Or perhaps instead of using R5 and R6, I can and should just use R13 and R14... as from browsing other discussions it seems these are free to use?

This raises an interesting question in general, if I have assembly code of the form

@newVar_i
M=i

for i=1,2,3.. then it will set RAM[i] = i or thereabouts (depending what else there is in between). This may corrupt the stack etc. if such new labels are created at inconvenient places? (e.g., if such @newVar_i lines are present in the asm implementations of VM_code commands like "lt" etc.)

No, it would set RAM[newVar_i] = i.

The only variable names that your VM translator should generate are for variables in the static memory segment. If your code needs to use a variable, then it needs to use R13 through R15. That's its scratchpad.

[kb-math]

Thanks for the clarification. This approach works well.