Debugging Suggestions?

[blossoms75]

Is there a decent way to debug the assembly code using the CPU Emulator?

I've tried:
1. Writing comments prior executing different commands (so I can read them in the asm file)
2. Running the code through the VM Emulator to get a better understanding of what's going on
3. Stepping through the code in the CPU  Emulator line by line
4. Trying to trace the VM and generated assembly code by hand

Are there any other things you've found helpful in debugging the assembly code?

[ivant]

That's basically what I used. Plus:

1. Use memory breakpoints to find when something changes in a way that you don't expect it to
2. Try to reproduce the problem with a small program.

The HACK assembly language is quite hard to read, so you should move to higher level as soon as possible. To that end, you need to implement the VM to HACK translator. After that the only times you need to look at the assembly is if you find some bugs in your implementation or if you're making optimizations.

[cadet1620]

blossoms75 wrote

Are there any other things you've found helpful in debugging the assembly code?

Another trick I've seen several people use is to write recognizable @ instructions at the beginning of the ASM for each VM statement. This makes it easier to find the start of the sequences in CPU Emulator's disassembly list.

@11111
@SP
AM=M-1
...

This also lets you set a "next VM command" breakpoint by breaking on A=11111.
After the @11111 you can write other numbers that can write other numbers that can be used to trigger breakpoints. For instance, you might want to be able to trigger on all 'return' statements so you could write an @22222 for returns.

To be able to find the ASM based on VM source line numbers, add something like @2nnnn.

You will want to have an easy way to turn these extra commands on and off, like a global variable at the beginning of your translator.


More work, but handy to have is to retrofit your Assembler to generate a listing file that shows the addresses for each instruction.

             // This file is part of the materials accompanying the book
             // "The Elements of Computing Systems" by Nisan and Schocken,
             // MIT Press. Book site: www.idc.ac.il/tecs
             // File name: projects/06/max/Max.asm

             // Computes M[2] = max(M[0], M[1])  where M stands for RAM
    0     0     @0
    1  FC10     D=M              // D=first number
    2     1     @1
    3  F4D0     D=D-M            // D=first number - second number
    4    10     @OUTPUT_FIRST
    5  E301     D;JGT            // if D>0 (first is greater) goto output_first
    6     1     @1
    7  FC10     D=M              // D=second number
    8    12     @OUTPUT_D
    9  EA87     0;JMP            // goto output_d
   10        (OUTPUT_FIRST)
   10     0     @0
   11  FC10     D=M              // D=first number
   12        (OUTPUT_D)
   12     2     @2
   13  E308     M=D              // M[2]=D (greatest number)
   14        (INFINITE_LOOP)
   14    14     @INFINITE_LOOP
   15  EA87     0;JMP            // infinite loop

(In my listing file, the ROM addresses and @ instruction values are decimal and the instruction values are hexadecimal.)

--Mark

[blossoms75]

Hi thank you both for the suggestions. Putting recognizable commands in my vm helped me narrow down the problem. I'm trying to implement the breakpoint idea, but I think I'm doing something wrong because it's affecting the flow of the program (which I don't think should be happening).

So @cadet1620, you said:

After the @11111 you can write other numbers that can write other numbers that can be used to trigger breakpoints. For instance, you might want to be able to trigger on all 'return' statements so you could write an @22222 for returns.

What you're saying there is that you can add a recognizable breakpoint, and when you get to a point where you want to see what is going on in the assembly, you write the output of the register you're interested in to that breakpoint? So then, you can go to that memory location and see what the output is?

[cadet1620]

cadet1620 wrote

After the @11111 you   can write other numbers that   can write other numbers that   can be used to trigger breakpoints.

oops -- cut and paste and paste again editing strikes again.

All I meant was that by using different marker numbers you can put a breakpoint on all of a single type of VM command:

For instance mark call statements as

    @11111
    @20001
    {call vm command asm code}
    @11111
    {next vm command}

then an A=20001 breakpoint will stop at the beginning of all call commands.

Assuming that your ASM code for individual VM commands does not rely on the A Register value set by a previous VM command, and that the only marker instructions you add are @ commands at the very beginning of the ASM for VM commands, they should not affect the program flow.  

--Mark