One failed comparison with FibonacciElement and StaticsTest

[pstrawn]

I have almost finished Ch. 8: my code passes for BasicLoop, Fibonacci, NestedCall, and SimpleFunction. However, below are the failed comparisons for the last two programs.

FibonacciElement
Test Output
| RAM[0] |RAM[261]|
|    262 |      3 |

My Output
FibonacciElement
| RAM[0] |RAM[261]|
|    262 |      4 |

StaticsTest
Test Output
| RAM[0] |RAM[261]|RAM[262]|
|    263   |     -2       |      8 |

My Output
FibonacciElement
| RAM[0] |RAM[261]|RAM[262]|
|    263   |     8       |      8 |

I've tried everything I can to debug: comparing assembly commands and tracing code, running the VME.tst file, double-checking how I handle labels and returns.

I have a feeling it has to do with how I handle the return-address in my assembly code for `call f n`, but if that were the case, wouldn't NestedLoop and SimpleFunction fail as well?

Maybe the more likely culprit is how my bootstrap code works? That's the only new code that's not tested in the other four (from what I can tell).

My logic with that is as follows (in pseudocode):
// Set SP to 256
// Call the writeCall() method from within writeInit() passing as arguments Sys.init and 0

On reflection, maybe that second step is the wrong way to set everything up. It seems almost too easy, which means it's probably not right. Any pointing-in-the-right-direction would be greatly appreciated. Thank you! I see the end in sight once I get over this hump of Ch. 8!

[cadet1620]

Your bootstrap looks OK.

The new things in the failing tests are:
    recursion (FibonacciElement) -- beware of any temp RAM data the you might require to be maintained across a function call.
    static variables in multiple classes (StaticsTest) -- double check that static variables get names that are unique between VM files.

If you are not already doing so, write the VM source code in the ASM output as comments. This will help you find your way around in your ASM.

// push $Cordic 4
    @RIP$421
    D=A
    @$PUSH_MEM__Cordic.4$
    0;JMP
(RIP$421)

// add
    @RIP$422
    D=A
    @$STACK_add$
    0;JMP
(RIP$422)

// pop pointer 1
    @RIP$423
    D=A
    @$POP_MEM_4$
    0;JMP
(RIP$423)

[Don't try to understand the ASM in the above example; it is the output from a highly optimized  translator.]

If you want to, email me the ASM you generate (with source comments) for the failing tests and I'll take a look at it when I get the chance.  I'm on vacation this week but should have time available in the mornings and evenings.

--Mark

[omar]

I had the same output, I initialized the stack in the bootstrapper to 261 and it worked.

[pstrawn]

Update: I cleaned up (or so I thought) how I handled R13-R15. It didn't help with FibonacciElement, but now I get the right output for StaticsTest. It must be something with how I (mis)handle recursion. I do print the VM code as comments, so I'm trying to trace my output by hand using the CPUEmulator and my commented code. Thanks for the pointers - I will keep at it for a little while longer before sending an email. I do appreciate the guidance immensely!

[cadet1620]

Glad to see you still working on it; I like tenacious students.

One thought about the recursive failure, be sure that you are saving the return address on the stack, not in one of R13-15.  I remember seeing one student's translator that generated code that had return using a value chat call stored in one or the R registers...

--Mark

[Moshe]

I have the same problem like pstrawn. after fixing my static address issues I passed the StaticsTest but still getting the same output on FibonacciElement test. I check that the return address value is pushed to the stack. Any other ideas? How did pstrawn fixed his problem?

[warnian]

This project has been tough, I have worked through several issues but the last one I seem to not be able to get has to do with Fibonacci element.

My output file is:

RAM[0]=262 RAM[261]=4

whereas the correct compare file is:

RAM[0]=262 RAM[261]=3


This is the last issue I am having and I cannot seem to pinpoint where or why this is only one number off. It seems like the exact same problem the poster above had. Any tips for where to look on this one?

Thank you,

[warnian]

Hi Everyone,

I figured this out I believe. If you are having a similar issue I would advise to re visit your writeCall implementation, this is where the problem existed in mine. For example I was writing the push local, arg, this, that as in my original push implementation. However, these are not treated like the original they should be treated as "static" variables since they have their own stack if that makes sense. In their stack they are this, that, etc. but in the overall stack they are written as a static variable.

Also make sure your nestedCall works too, I had originally (foolishly) skipped it since I thought the fibonacciElement was so close, but this ended up being a fluke and the nestedCall test advised me to where my errors were in a round about way.

Hope this helps.

[rodrigomlp]

I am stuck with the same bug and I am a bit confused about the talk of looking at the RAM temp data and treating the push variables as static. Can you guys clarify what that means, last part of my program not working.

[ivant]

rodrigomlp wrote

I am stuck with the same bug and I am a bit confused about the talk of looking at the RAM temp data and treating the push variables as static. Can you guys clarify what that means, last part of my program not working.

Sorry for the late reply, I just saw your message.

I find the comments from warnian confusing, so if you are referring to them, I suggest you just ignore them. You should instead reread chapter 8 as well as the previous messages by cadet. If you still can't solve your problem, please give a bit more info on what you're trying and what is happening, so we can help.

[rodrigomlp]

I got it, thanks!

[el_turi]

Hi,

I was in fact using R14 to store the *(FRAME-5). After reading your comment on using a variable in the stack I switched to using a variable @RET. However, I'm still getting the same result as before:

| RAM[0] |RAM[261]|
|    262 |      4 |

Why is it discouraged to use one of the temporary registers to store the RET address?

My code is already passing the other tests in chapter 8, FibonacciElement is the only one failing.

Update:
I returned my code as it was before i.e. using R13 for FRAME and R14 to temporarily store RET. There was no problem with my use of the registers this since the temporary values stored in them are consumed within the implementation of the "return" command. The problem with my code was that it was not treating lines with inline comments as code, lines like this one in the .vm file:

"lt                     // checks if n<2"

were not being translated to ASM by my translator program. Adding the VM code as a comment before the generated assembly code(as pointed out in another post in the forum) helped me to spot this problem.

Finally my code passed all of chapter 8's tests ;-)

[WBahn]

If you use @RET, then that means that you are writing to whatever static address was assigned to the variable RET by the assembler. Let's say it assigned RAM[20] to RET.

Now your first function, let's call it Fred, calls the Sue function. The return address within Fred that is the place where Fred's execution should be resumed is then written to RAM[20] (overwriting whatever was there). So what happens if Sue then calls the Tim function? The return address within Sue where execution should resume when we return from Tim is written to RAM[20], overwriting whatever was there, which means that the return address within Fred is now lost. This is why it needs to be stored on the stack -- because every call to a function has it's own stack frame and so it has a place to store the return address it needs to use when it is finished executing.