FibonacciElement.cmp

[John Douma]

When I run FibonacciElement.tst in the CPUEmulator my output differs from the output of FibonacciElement.cmp. However, If I run FibonacciElement inside of the VMEmulator the state of RAM agrees with the output from my VM translator. Is there an updated .cmp file or am I making a mistake?

[cadet1620]

John Douma wrote

When I run FibonacciElement.tst in the CPUEmulator my output differs from the output of FibonacciElement.cmp. However, If I run FibonacciElement inside of the VMEmulator the state of RAM agrees with the output from my VM translator. Is there an updated .cmp file or am I making a mistake?

There is no updated cmp file to my knowledge.  I'm guessing that you are missing some initialization in your translator output.

When you open the FibonacciElement directory in VMEmulator, it initializes the SP and sets the PC to SysInit.
SysInit is not called.  The FibonacciElementVME.tst script explicitly sets the SP so that it appears that SysInit was called.

If FibonacciElementVME.tst works and FibonacciElement.tst doesn't, there's probably something wrong with your call to SysInit.

--Mark

[John Douma]

If you look at the code in Sys.vm you will see that the .cmp file is not correct. The bootstrap code sets the stack pointer to 256. Sys.vm pushes 4 onto the stack and then calls the fibonacci function in Main.vm. When this returns it should have replaced the 4 with fib(4) and thus the stack pointer should be 257. Therefore, SP = Ram[0] = 257 which contradicts the value in FibonacciElement.cmp.

The same is true in StaticsTest.cmp. Ram[0] should be 258. These results are verifiable in the VMEmulator.

[John Douma]

I think the problem is that FibonacciElement.cmp and StaticsTest.cmp are assuming the *VME.tst scripts are running instead of the *.tst scripts. I say this because the values for Ram[0] are consistent with an initial stack pointer value of 261 which is what the VME.tst scripts explicitly do.

I believe all tests are meant to be done without bootstrapping code. This would be consistent with the ProgramFlow tests and the SimpleFunction test which fail if bootstrapping code is enabled.

[cadet1620]

The VM emulator does not initialize the same way as the CPU emulator.

For the FibonacciElement program (and for the remainder of the book), the bootstrap code generated by your VM translator must do a 'call Sys.Init 0' so that there is a stack frame created on the stack. At the entry to Sys.Init the stack should look like this:

256 return address
257 saved LCL  (undefined value)
258 saved ARG  (undefined value)
259 saved THIS (undefined value)
260 saved THAT (undefined value)

Sys.Init calls Main.fibonacci which returns with its return value pushed on the stack:

261 return value from Main.fibbonacci (3)

and the SP is 262. (Sys.vm for this test is a bit nonstandard in that it does not pop the return value.)

You can look at projects/06/Pong.asm to see code generated by the authors' VM translator that does this.

Note that after you make this change in your bootstrap code, the prior tests no longer pass their tests. I wrote my VM translator to have a command line option to generate the old bootstrap so that I could easily do regression testing.

--Mark

[John Douma]

That would explain it. My initialization does not do a translation of "call Sys.init 0". Instead I set the value for the stack pointer and then jump to Sys.init. Essentially, I do the following.

@256
D=A
@SP
M=D
@Sys.init
0;JMP

It seems like that should be the correct thing to do since the bootstrap code is technically not a function so it has no segments to preserve. If I leave my translator as is, will this affect my compiler in the upcoming chapters?

[cadet1620]

John Douma wrote

It seems like that should be the correct thing to do since the bootstrap code is technically not a function so it has no segments to preserve. If I leave my translator as is, will this affect my compiler in the upcoming chapters?

The bootstrap code is not a function, but Sys.init is.  I chapter 12 you'll end up writing it in Jack.  At a minimum the bootstrap also needs to set LCL (and maybe ARG depending on how your function entry/return code works).  The easiest way to ensure that everything's ready to go is to do a real vm call.  Easy enough to do since you can just call your call command translation code.  I also followed the call to Sys.init with an infinite loop.  It's not supposed to return, but...  Two instructions are cheap insurance.

--Mark