3

I've tried with both QtSpim 9.1.16 and 9.1.17, all of them "cut" the first 2 chars of an input string, setting them to 0x0, other ASCII chars are correctly saved into buffer. That's my snippet, even though other code I've found on the internet brings to the same result:

.data               # ROM area
    str_input:  .asciiz "Digita la stringa che vuoi controllare (max 10 caratteri): "

.data               # RAM area
    buffer:     .space 11

.text
.globl main
    main:   li $v0, 4
            la $a0, str_input
            syscall             # syscall to print user message
            #------
            la $a0, buffer
            li $a1, 11
            li $v0, 8
            syscall

For example, if I type in '12345', that's the memory dump:

User data segment [10000000]..[10040000]
[10000000]..[1000ffff]  00000000
[10010000]    69676944  6c206174  74732061  676e6972    D i g i t a   l a   s t r i n g 
[10010010]    68632061  75762065  6320696f  72746e6f    a   c h e   v u o i   c o n t r 
[10010020]    616c6c6f  28206572  2078616d  63203031    o l l a r e   ( m a x   1 0   c 
[10010030]    74617261  69726574  00203a29  3433000a    a r a t t e r i ) :   . . . 3 4 
[10010040]    00000035  00000000  00000000  00000000    5 . . . . . . . . . . . . . . . 
[10010050]..[1003ffff]  00000000

Am I missing something about QtSpim?

  • I'm unable to reproduce your problem [with 9.1.17]. I did a code review. I added a syscall 4 to echo back the buffer and then a syscall 10 to exit the program. Unless you're single stepping, after your syscall 11, you're "falling off the edge of the world" (i.e. what code gets executed?). But, here, both the echo of the data and the hex dump match expected results. – Craig Estey Jun 10 '16 at 20:48
  • I was single stepping actually, that's what our teacher advised us to do. If I let the program run normally, there's nothing wrong... oh and that you for the syscall 10 hint, I wasn't aware of it. But could you explain why single stepping causes such a weird behavior? For example, MARS is a good guy and doesn't misbehave. – LivingSilver94 Jun 10 '16 at 21:20

1 Answers1

1

Per my top comments, I had added a syscall 4 to echo the buffer contents and a syscall 10 to exit the program.

spim can be quirky (re. "falling off the edge of world"). That is, if the program is not terminated correctly.

When I added the two syscalls, I gave the program a "soft landing zone" for single step, which was not needed for "full run" mode. Thus, I inadvertantly adulterated the program in a way that masked the spim simulator's bug.

When I reverted to your exact program, I was able to reproduce your problem. It appears that spim does weird things if the last instruction in the text segment is a non-exit syscall during single step.

Adding [even] a nop after your syscall 11 fixes the problem.


I've used both, but I prefer mars: http://courses.missouristate.edu/KenVollmar/MARS/ It is much better organized for debug/single step, diagnostic messages, setting bkpts, data views--YMMV.

I had previously downloaded and hacked up the source to both simulators. I've been doing some cleanup and adding some features. I'm not the original author, but I've become somewhat familiar with the code.

I'll have to hook up gdb to spim and see what is happening. But, I can already say that the code path is somewhat different for step vs run in QtSpim

Craig Estey
  • 30,627
  • 4
  • 24
  • 48
  • Ok, I'm moving to MARS then. My exam is due in three days and I don't have the time look after spim bugs. Too bad, I prefer Qtspim, its GUI is more neat. – LivingSilver94 Jun 11 '16 at 09:06