|
|
|
|
Hello -
I successfully get .out files for all programs in the FunctionCalls and ProgramFlow folders, but only one matches the .cmp file provided. Can anyone give me some advice on where to start troubleshooting? I'm not sure what the appropriateness might be of attaching the .out files I'm getting, but I'm happy to provide them if that will help.
thank you
jr
|
|
Administrator
|
copygirl4848 wrote
Hello -
I successfully get .out files for all programs in the FunctionCalls and ProgramFlow folders, but only one matches the .cmp file provided. Can anyone give me some advice on where to start troubleshooting? I'm not sure what the appropriateness might be of attaching the .out files I'm getting, but I'm happy to provide them if that will help.
thank you
jr
You should do the tests in order:
no bootstrap
ProgramFlow/BasicLoop
ProgramFlow/FibonacciSeries
FunctionCalls/SimpleFunction
FunctionCalls/NestedCall *
add/enable bootstrap
FunctionCalls/NestedCall *
FunctionCalls/FibonacciElement
FunctionCalls/StaticsTest
* NestedCall can be run with or without bootstrap code.
It is important that when one of the tests fails to compare, that you fix your code so that the test passes before you proceed to the next test.
It sounds like you have written your complete VM translator. You will need to temporarily disable writing the bootstrap code so that you can work on the earlier tests, or as I did, add a command line option to skip writing the bootstrap.
(Yes, it's OK to post .out files.)
--Mark
|
|
|
Thank you. Will fiddle with the bootstrapping. Very, very new to all of this (first year computer programming major) so please excuse silly questions.
In the meantime, here is my .out file results, with the .cmp values above. "Comparison failure at line 2" is the error I get in the CPU Emulator, which makes total sense as the RAM location values don't match.
| RAM[0] |RAM[256]|
| 257 | 6 |
| RAM[0] |RAM[256]|
| 321 | 53 |
|
|
|
Is it expected that my translator without bootstrap code would fail on the NestedCall comparison? Everything else worked as expected when I removed and added the bootstrap. Thanks again.
|
|
Administrator
|
Did you get BasicLoop (prior post) working?
NestedCall should work both with and without bootstrap code. If it works for you with bootstrap code, but fails without bootstrap code, I'd like to see the ASM generated for each case. Please mail the two asm files to me.
--Mark
|
|
|
I apologize, I took poor notes when I initially ran the test scripts.
BasicLoop, Fibonacci Series, FibonacciElement, and StaticsTest all work fine. BasicLoop and FibonacciSeries without bootstrap code, and FibElement and StaticsTest with it.
Neither NestedCall or SimpleFunction work with or without bootstrap code. I sent you the .asm and .out files. Appreciate the time.
jr
|
|
|
How do we test NestedCalls without bootstrap? won't the first 5 lines (reference to sys.init) cause the incorrect output? I suspect I may not your response here, at least for the rest of the code, Sys. is just a harmless prefix to other, regular functions. But what about the prologue of the code?
|
|
Administrator
|
Old test code snuck back onto the web site (again, sigh) see this news post and get the files from the .zip. This old code may be causing the problems you are seeing.
When you run NestedCall without bootstrap, the test script initializes SP and a stack frame on the stack that looks as if bootstrap code had called Sys.init().
When you run with bootstrap, the test scrip still does that initialization, but the bootstrap ignores all that and sets SP to 512 and calls Sys.init() which makes a stack frame.
The net result is that the environment is the same when Sys.init() starts running.
--Mark
|
|
|
Bummer. That one is decidedly longer and more complex to debug than the one I had been working on. I'll have to start over.
|
|
Administrator
|
The_Larks wrote
Bummer. That one is decidedly longer and more complex to debug than the one I had been working on. I'll have to start over.
Use the stack pictures in NestedCallStack.html.
Set PC breakpoints on the instruction after all the (function.name) labels. and you can check the stack frames for correctness.
--Mark
|
|
|
OK, so I think I have discovered the problem. Not surprisingly, my program does in fact set up the stack frame properly at each function call, and it calculates and returns the correct value as it unwinds. The *difference* between the .tst and .cmp files is that the .tst files stores the return values in temp0 and temp 1, so that at completion, R5 and R6 are 135 and 246, respectively. I mean, is that the intended behavior? So somehow my code correctly stores the return value after each return into the slot just after the *SAVED* that (or *local* temp0), but not the *final* return value in the absolute temp0 (R5, and then R6 for the second return value).
|
|
Administrator
|
The_Larks wrote
... the .tst files stores the return values in temp0 and temp 1, so that at completion, R5 and R6 are 135 and 246, respectively. I mean, is that the intended behavior? So somehow my code correctly stores the return value after each return into the slot just after the *SAVED* that (or *local* temp0), but not the *final* return value in the absolute temp0 (R5, and then R6 for the second return value).
Yes, the sys.vm code pops the return values from Sys.main and Sys.add12 into temp segment 0 and temp segment 1, respectively.
function Sys.init 0
...
call Sys.main 0
pop temp 1 <--- Return value stored in temp 1
...
function Sys.main 5
...
call Sys.add12 1
pop temp 0 <--- Return value stored in temp 0
...
Your symptom, that the values is popped into local segment 0, indicates that the code you are generating for "pop temp #" is incorrect. It's interesting that this was not detected in one of the project 7 tests. I'll need to take a look at them.
Note that the temp segment is a single fixed address segment (like pointer), not stack based.
--Mark
|
|
|
Yes, look at this now. Just set breakpoint for that line of code… so I should be able to pinpoint and fix it On Nov 10, 2016, at 1:36 PM, cadet1620 [via Nand2Tetris Questions and Answers Forum] < [hidden email]> wrote:
The_Larks wrote
... the .tst files stores the return values in temp0 and temp 1, so that at completion, R5 and R6 are 135 and 246, respectively. I mean, is that the intended behavior? So somehow my code correctly stores the return value after each return into the slot just after the *SAVED* that (or *local* temp0), but not the *final* return value in the absolute temp0 (R5, and then R6 for the second return value).
Yes, the sys.vm code pops the return values from Sys.main and Sys.add12 into temp segment 0 and temp segment 1, respectively.
function Sys.init 0
...
call Sys.main 0
pop temp 1 <--- Return value stored in temp 1
...
function Sys.main 5
...
call Sys.add12 1
pop temp 0 <--- Return value stored in temp 0
...
Your symptom, that the values is popped into local segment 0, indicates that the code you are generating for "pop temp #" is incorrect. It's interesting that this was not detected in one of the project 7 tests. I'll need to take a look at them.
Note that the temp segment is a single fixed address segment (like pointer), not stack based.
--Mark
To unsubscribe from .out file does not agree with .cmp file, click here.
NAML
|
|
|
Ok, yes temp is fixed and my pop temp# is correct. The problem is my liberal use of R13. When The code goes to pop temp 1, it correctly finds the stack pointer and the location of the return value (246), but then when it loads R13 the second time, it actually loads the value inside R13 which is a memory address to somewhere other than my return value. On Nov 10, 2016, at 1:36 PM, cadet1620 [via Nand2Tetris Questions and Answers Forum] < [hidden email]> wrote:
The_Larks wrote
... the .tst files stores the return values in temp0 and temp 1, so that at completion, R5 and R6 are 135 and 246, respectively. I mean, is that the intended behavior? So somehow my code correctly stores the return value after each return into the slot just after the *SAVED* that (or *local* temp0), but not the *final* return value in the absolute temp0 (R5, and then R6 for the second return value).
Yes, the sys.vm code pops the return values from Sys.main and Sys.add12 into temp segment 0 and temp segment 1, respectively.
function Sys.init 0
...
call Sys.main 0
pop temp 1 <--- Return value stored in temp 1
...
function Sys.main 5
...
call Sys.add12 1
pop temp 0 <--- Return value stored in temp 0
...
Your symptom, that the values is popped into local segment 0, indicates that the code you are generating for "pop temp #" is incorrect. It's interesting that this was not detected in one of the project 7 tests. I'll need to take a look at them.
Note that the temp segment is a single fixed address segment (like pointer), not stack based.
--Mark
To unsubscribe from .out file does not agree with .cmp file, click here.
NAML
|
|
Administrator
|
The_Larks wrote
Ok, yes temp is fixed and my pop temp# is correct. The problem is my liberal use of R13. When The code goes to pop temp 1, it correctly finds the stack pointer and the location of the return value (246), but then when it loads R13 the second time, it actually loads the value inside R13 which is a memory address to somewhere other than my return value.
You are doing extra work for pop temp. Since the base is a fixed address and the offset is also fixed, your VM Translator can compute the target address.
--Mark
|
|
|
Don’t need R13 for pop temp? On Nov 10, 2016, at 2:20 PM, cadet1620 [via Nand2Tetris Questions and Answers Forum] < [hidden email]> wrote:
The_Larks wrote
Ok, yes temp is fixed and my pop temp# is correct. The problem is my liberal use of R13. When The code goes to pop temp 1, it correctly finds the stack pointer and the location of the return value (246), but then when it loads R13 the second time, it actually loads the value inside R13 which is a memory address to somewhere other than my return value.
You are doing extra work for pop temp. Since the base is a fixed address and the offset is also fixed, your VM Translator can compute the target address.
--Mark
To unsubscribe from .out file does not agree with .cmp file, click here.
NAML
|
|
|
At any rate, that’s not the only mistake i’m making. The .html diagram is incorrectly labeled at the bottom, 2nd and 3rd column. You have PC 271 listed back to back at the end of stack frame for the image depicting “After Sys.add12” and “Before sys.main" On Nov 10, 2016, at 2:20 PM, cadet1620 [via Nand2Tetris Questions and Answers Forum] < [hidden email]> wrote:
The_Larks wrote
Ok, yes temp is fixed and my pop temp# is correct. The problem is my liberal use of R13. When The code goes to pop temp 1, it correctly finds the stack pointer and the location of the return value (246), but then when it loads R13 the second time, it actually loads the value inside R13 which is a memory address to somewhere other than my return value.
You are doing extra work for pop temp. Since the base is a fixed address and the offset is also fixed, your VM Translator can compute the target address.
--Mark
To unsubscribe from .out file does not agree with .cmp file, click here.
NAML
|
|
Locked
