3 ms·

This JITs & executes basic blocks but that doesn't seem correct with interrupt handling. Interrupts can of course occur in the middle of a basic block, which is

This JITs & executes basic blocks but that doesn't seem correct with interrupt handling. Interrupts can of course occur in the middle of a basic block, which isn't handled right now from what I can tell? It is a difficult problem to get cycle correct interrupts, no doubt.

chrisseaton 10y ago
I don't know anything about the architecture, but if an external source is causing the interrupt, how can could you observe that the interrupt was delayed until the end of a basic block? You can only run for so long before you reach the end of a basic block, so can you tell the nanosecond difference? And doesn't the routine triggering the interrupt wait until the interrupt is serviced, so how can it tell the difference as well?
- MackieLoeffel 10y ago
  Yes, thats exactly the reasoning, why it isn't a problem to handle the interrupts only between basic blocks. Qemu does something similar. The ATmega32 makes it easy in this regard, because it doesn't have exceptions/traps, which have to be executed synchronously (div by 0 isn't a problem, because there is no div instruction). JIT compiling for a x86 is far harder, because you have to make sure, that the traps are triggered at the correct points in time (e.g. a page fault, which happens during the fetching of an instruction).
  - chrisseaton 10y ago
    I only know about it because I do the same thing in dynamic programming languages. In Ruby you can redefine methods at any point, but in my implementation I only check if they have been redefined once per loop in the program. If another thread wants to redefine a method, it just waits a little while until all the other threads are ready. This means we can basically ignore the problem of method redefinition - as we only allow it when we are ready and then we can handle it slow-time.
- revelation 10y ago
  Well.. from the SRAM state, or any other side effect you can imagine? Making an example that shows the difference in servicing after every cycle vs. servicing interrupts only after a basic block is trivial. Configure a timer to interrupt in 10 cycles (or X) and then have a basic block writing 1, 2, 3, .. whatever to SRAM. Read the value in the interrupt routine. I imagine this is no big deal in x86 or similar where nobody wants or can achieve cycle-perfect interrupts anyway, but it is a common design goal for microcontrollers which have perfectly predictable timing and a lot less MHz. One cycle for an 8 MHz AVR takes 125 ns so you can imagine how servicing interrupts after basic blocks of varying length can introduce jitter into your microcontroller generated signals.
  - MackieLoeffel 10y ago
    The timer interrupt is indeed a special case and not very well implemented with the JIT compiler currently. The ticker even only ticks once per basic block, not once per instruction, when jit compiling, which is definitly not what you want, when you want to have predictable timing. But making the timing perfect was not a priority, since the programs, with which the VM was tested, also work well, when the timer interrupt only fires once in a while.
    - chrisseaton 10y ago
      This is the great thing about a JIT though. When someone installs a timing interrupt you can switch to different code that checks the timer frequently enough for hit the target.

chrisseaton 10y ago

I don't know anything about the architecture, but if an external source is causing the interrupt, how can could you observe that the interrupt was delayed until the end of a basic block? You can only run for so long before you reach the end of a basic block, so can you tell the nanosecond difference? And doesn't the routine triggering the interrupt wait until the interrupt is serviced, so how can it tell the difference as well?

MackieLoeffel 10y ago
Yes, thats exactly the reasoning, why it isn't a problem to handle the interrupts only between basic blocks. Qemu does something similar. The ATmega32 makes it easy in this regard, because it doesn't have exceptions/traps, which have to be executed synchronously (div by 0 isn't a problem, because there is no div instruction). JIT compiling for a x86 is far harder, because you have to make sure, that the traps are triggered at the correct points in time (e.g. a page fault, which happens during the fetching of an instruction).
- chrisseaton 10y ago
  I only know about it because I do the same thing in dynamic programming languages. In Ruby you can redefine methods at any point, but in my implementation I only check if they have been redefined once per loop in the program. If another thread wants to redefine a method, it just waits a little while until all the other threads are ready. This means we can basically ignore the problem of method redefinition - as we only allow it when we are ready and then we can handle it slow-time.
revelation 10y ago
Well.. from the SRAM state, or any other side effect you can imagine? Making an example that shows the difference in servicing after every cycle vs. servicing interrupts only after a basic block is trivial. Configure a timer to interrupt in 10 cycles (or X) and then have a basic block writing 1, 2, 3, .. whatever to SRAM. Read the value in the interrupt routine. I imagine this is no big deal in x86 or similar where nobody wants or can achieve cycle-perfect interrupts anyway, but it is a common design goal for microcontrollers which have perfectly predictable timing and a lot less MHz. One cycle for an 8 MHz AVR takes 125 ns so you can imagine how servicing interrupts after basic blocks of varying length can introduce jitter into your microcontroller generated signals.
- MackieLoeffel 10y ago
  The timer interrupt is indeed a special case and not very well implemented with the JIT compiler currently. The ticker even only ticks once per basic block, not once per instruction, when jit compiling, which is definitly not what you want, when you want to have predictable timing. But making the timing perfect was not a priority, since the programs, with which the VM was tested, also work well, when the timer interrupt only fires once in a while.
  - chrisseaton 10y ago
    This is the great thing about a JIT though. When someone installs a timing interrupt you can switch to different code that checks the timer frequently enough for hit the target.