I need a more advanced test after "FibonacciElement"

[VonLoewe]

So I've been working on an optimizing VMTranslator for way too long now. So far it's passed all of the tests supplied in projects 7 and 8, and it generates a Pong.asm file of only around 17k lines without any dead code removal. But this Pong.asm always fails to run on the CPUEmulator.

I've gone through several debugging attempts and fixed errors whenever I got an illegal memory address. But now, I've reached a point where Sys.halt is being called and execution ends on an infinite loop. Obviously, some part of the code is going into Sys.error, which in turn calls Sys.halt. I'm trying some debugging techniques still to trace which function is causing the error, but I feel like Pong is a way too big a leap from FibonacciElement, and the code is so long it's impossible to find errors by stepping code one line at a time.

So my question is, can anyone recommend an intermediate program, more complex than Fibonacci, but not as complex as Pong, to help with debugging? I haven't even started on the compiler or jack yet (which yes, I know is bad, but I've been having a lot of fun with optimizing VM) so I don't have any programs of my own.

[WBahn]

You might try doing a bit of static analysis on your code. Have your assembler output the symbol table indicating which symbols are for variables and which symbols are for labels. If any of the labels are low valued, then it is likely that they were assembled as variables.

You can also modify your VM Translator to output ROM addresses as comments on every instruction in the .asm file, which makes debugging in the CPU emulator a whole lot easier. You can take this a step further and have it generate a function table that has the ROM addresses of the entry point of every function in the program.

[VonLoewe]

I'm not sure I understand your first suggestion, but the second is brilliant.
Though I was waiting to see if I could get Pong to run before adding a function call table, since that's naturally a part of dead code removal which I was going to do next. But I will do it right now and see if it can help me debug. I also didn't think about tracking the ROM address; I've really been struggling finding stuff in the .asm file and this is a great idea.

About the static analysis though, why do you suspect that could be an issue? I'm assuming the CPUEmulator would never get variables and labels mixed up, and it should be simple enough to see if there's any problem with the methods that translate labels and push/pops to static. Also, my assembler does labels and variables in separate passes, precisely to avoid mixing them up. Though again, I'm not using my assembler at all at this point.