bug in StaticsTest

[mariominaccia]

Hello,

I think I discovered a bug in the StaticsTest.tst file: the system RAM[0] is initialized at 256, while the StaticsTestVME.tst inizialize it at 261 (which is coherent with the StaticsTests.cmp results).

In order to get a correct comparison, StaticsTest.tst should be modified with set RAM[0] 261 in line 11.

[WBahn]

I'll take a look when I get a chance, but I'm pretty sure that this is not a bug, but rather an artifact of the test scripts assuming that your VM translator doesn't yet generate the bootstrap code.

[dolomiti7]

It is not a bug, but intended to be like that. It has to do with the bootstrap code and a subtle difference between CPU and VM emulators. By convention the bootstrap code should call Sys.init. This call will increase SP by +5, so when entering Sys.init SP should be 261. The CPU Emulator (and the test script) leaves it to you to ensure that your bootstrap code performs that call, therefore it starts with 256.

The VM Emulator on the other hand, just starts by convention directly with Sys.init with SP set to 256. So SP would be off by 5 compared to the CPU emulator. In order to make the 2 test scripts generate the same output, SP is set to 261 in the VM script to emulate the impact of the bootstrap call to Sys.init.

So from testing perspective it is absolutely correct. You can say that the VM test script cannot and doesn't test your bootstrap code and therefore starts at 261 while the CPU test script includes the test for your bootstrap code.

Technically there is no reason why you couldn't just jump into Sys.init (without a full scale call) as long as SP is set correctly (and LCL in case Sys.init uses locals), however the test scripts require that your bootstrap code generates that call. My own VM translator will just fall-through from the bootstrap into Sys.init with SP=256 and no call or jump. I just added an optional flag which will enforce a call to Sys.init to satisfy the test scripts if required.