Closed unbibium closed 11 years ago
The same issue as mine https://github.com/DCPUTeam/DCPUToolchain/issues/223 I can't use dcputoolchain emulator because of this anymore :( A very serius bug!!
this will be merged into master soon, i accidentally fixed it in the new compiler branch :)
i'm sorry this took so long, I was really busy the last few days, and our other main devs have quit or taken a longer break from the toolchain.
@unbibium @hyperfang8 : can you confirm the fix please?
I will, once I figure out how I built it in the first place -- it's complaining that it can't find SPHINX_EXECUTABLE and refusing to build anything, even though it says only the IDE requires it.
Is it part of the development build up on the main website now?
OK; it looks like it works now.
reopening this issue, interrupts that get triggered from actual hardware (e.g. keyboard in vm_hw_keyboard.c) still have this issue.
This needs some redesign of our interrupt code. I will get on it
this is now properly fixed. no more issues with interrupts!
neat. Is there a test for this? I'd like to try running it on the various other emulators and bother those authors too.
We should construct some tests for this in our test suite. I'll prototype some tests this morning but as I don't have my PC it'll be impossible to actually run them.
I recompiled off master yesterday, and still got the kind of random behavior I generally expect from interrupt problems. I think I'll put together a python filter that detects skipping problems and pipe dtemu through it.
The DCPU-16 specification version 1.7 states: "Interrupts are not triggered while the DCPU-16 is skipping," implying that it should queue interrupts until the skip flag is clear. DTEMU does interrupt while sipping, causing unpredictable behavior.
I discovered this while writing a program that uses a clock interrupt, and I find that if the interrupt occurs immediately following a false IF opcode, then the first instruction of the interrupt is aso skipped. In the -d dump, it looks like this:
... then at the end of the routine:
The instruction at 0xA282 should have been skipped, not the one at 0xB32E.