aluds.go

[Yzgll]

There are a lot of things I don't understand when I modify my instructions based on what mgpusim has implemented.
First of all, dst0offset and data0offset when do they equal uint(8 + 64*4), uint(8 + 64*4 + 256*4), uint(8 + 64*4 + 256*4*2) and how do we get this?
Second, when the instruction is described as DS[ADDR+offset0*4] = D0; DS[ADDR+ Offset1*4] In this case, addr0 := layout.ADDR[i] + Int.offset0 *4 and addr1 := layout.ADDR[i] + Int.offset1 *4 I can understand, But in the case of DS[A] = D0 and R = DS[A], can addr only be addr0 := layout.ADDR[i] + st.offset0?
Third, the runDSREAD2B32 function needs to write data to two registers why only dst0offset and not dst1offse?
Fourth, how can we ensure that DS[A] = D0[7:0] reaches the lower eight? &0xFF?
Fifth, go test can't run the test file, showing something undecided, but the file is fine.

[syifan]

1. I guess you are asking how the 8+64*4 is calculated? It is the data located in the scratchpad (models the input/output registers of ALUs). You can check the scratchpad layout here.
2. Can you check the ISA documentation? I do not remember the details.
3. It looks like a bug in our disassembler? The ROCm disassembler generates both offsets. Can you confirm?
4. I do not understand this question. Can you give me more context?
5. What about just run go test without a file specified?

[Yzgll]

Sure, I'll do my best. But how should we resolve the issue where the instructions in the disassembly differ from those in kernels.asm?

[syifan]

It is the same debugging process. You will need to identify the code that generates the wrong instruction and find out what the problem is.

[Yzgll]

Since you experience a panic when you disassemble the program with MGPUSim, can you fix MGPUSim so that it can at least disassemble the whole file?

I found the cause; it seems to be my error rather than MGPUSim's. After I modified this https://github.com/sarchlab/mgpusim/blob/v3/insts/inst.go#L299, it could disassemble the entire file. The panic at ds_read_i8 is gone, and ds_write_b8 has also changed.

Figure 1："v1" was supposed to be the destination register, but it has now become the source register, while the destination register is nil.

Figure 2："The destination register is nil."

Here is my analysis:
I believe the root cause is the incorrect implementation of the instruction in the aluds.go file, with the error likely in the calculation of 8 + 64 * 4. To be honest, I also reviewed the scratchpad layout, but I still don't understand how this calculation is derived, so I assigned the value directly without calculating it. It happened to pass the test. Therefore, I think this is the key issue.
Do you think my analysis is reasonable? Or could there be other reasons?

[syifan]

I do not think the error has anything to do with aluds.go. The aluds.go code is for the emulator. The disassembler does not need to call the emulator code.

[Yzgll]

Yes, you are right. I also thought about it for a long time yesterday. The disassembled file is kernels.hsaco, which is compiled from kernels.cl and has nothing to do with aluds.go.
I found the cause of the panic. When I disassembled, I printed out the relevant instruction information and found that I.Dst = nil. However, at https://github.com/sarchlab/mgpusim/blob/v3/insts/inst.go#L303, I.Dst.String() was called. Therefore, ds_read_i8 caused the panic, while ds_write_b8 (opcode 30) did not call this.Why is their Dst empty?



Another issue I've discovered is that in the disassembly, the Dst and Addr of ds_write_b8 seem to be reversed compared to kernels.asm