dtemu problem

[orlof]

sry for this poor issue report:

I was testing admiral with toolchain. admiral's edit() function open editor in DCPU correctly with lettuce and devkit, but leaves empty screen with dtemu. Is it just me or is it dtemu?

tested with latest stable and experimantal http://bb.dcputoolcha.in/builds/windows/dists/dcputoolchain-windows--1a7c902d4f6f6e07e546506e7516f4056df993eb.exe

[hach-que]

This issue has been known for quite some time, but we're unsure of where the issue lies and it's almost impossible to track down (because Admiral is such a large and complex program). We really need a small program that demonstrates the issue before it can be solved.

[orlof]

I can try isolate the problem and provide you with a small test program.

[orlof]

I have isolated the problem line, but I am unable to provide you with test program. Here are my findings. dtemu makes error in edit.dasm16 line 554:

:win_normalize_6
  ifl [cur_y], SCREEN_ROWS            <- THIS LINE
    set pc, win_normalize_5

  ; bow_line = nextline (bow_line);
  jsr nextline  

I have verified that dtemu reaches the line 554 with [cur_y]=0 and SCREEN_ROWS=12. For some reason it still doesn't branch to win_normalize_5, but instead continues to jsr nextline.

[orlof]

...and it is getting even more wierd. I tried to disassemble what instruction is in win_normalize_6 and i didn't see anything sane. Is it possible to somehow debug that a bit more.

Basically I ran admiral and as 1st command I gave "edit()". if I could set a breakpoint to win_normalize_6 and disassemble from there.

[orlof]

Today I am even more confused. I didn't get debugger to work at all with admiral, so I added simple print statements to show what is in memory location win_normalize_6:

:win_normalize_6 ifl [cur_y], 12 ; cur_y >= LINES set pc, win_normalize_5

set a, [win_normalize_6]

; opcode
set c, '0'
ifb a, 16
    set c, '1'
jsr screen_add_char

set b, a
and b, 15
set c, b
ifg b, 9
    add c, 'a' - 10
ifl b, 10
    add c, '0'
jsr screen_add_char

; b
set b, a
shr b, 5
and b, 31

set c, '0'
ifb b, 16
    set c, '1'
jsr screen_add_char

set b, a
and b, 15
set c, b
ifg b, 9
    add c, 'a' - 10
ifl b, 10
    add c, '0'
jsr screen_add_char

; a
set b, a
shr b, 10
and b, 63

set c, '0'
ifb b, 16
    add c, 1
ifb b, 32
    add c, 2
jsr screen_add_char

set b, a
and b, 15
set c, b
ifg b, 9
    add c, 'a' - 10
ifl b, 10
    add c, '0'
jsr screen_add_char

:test set pc, test

This printed out161616, which means IFL [i + literal], [i + literal]

but because all the values are (opcode, b, a) are 16 I think there might be something even more broken. I am ot even sure if the SHR instruction works. I believe I had some weird results from it during debugging.

[hach-que]

There are test suites for the math operations which are generated to test most possibilities, however we don't have test suites for the rest.

I'd suggest having a look at how the math op tests are generated and defining test suites for relevant instructions.

[orlof]

I believe that dtemu has a bug somewhere deep inside, but I don't have enough time to start studying it any deeper.

Here is the last piece of information that I received by monitoring the contents of the memory locations:

Problem is that the IFL statement below does not execute the SET PC, even though the memory locations proove that it should (IFL 0, 12).

0x7fd6 IFL [0x0173], 12 0x000c 0x0173 0x7f81 SET PC, 0x293e <- THIS BRANCH DOES NOT HAPPEN 0x293e [0x0173]=0x0000

I tested the code also by changing the IFL to IFG, IFE and IFU:

IFG, IFL, IFE -> DOESN'T BRANCH IFU -> DOES BRANCH

[jdiez17]

IFE worked fine for me.

Just pushed a fix for IFL and IFG. Sorry about that.