tinygo
tinygo copied to clipboard
tinygo-org
riscv: allow interrupts to wake the scheduler
This PR allows interrupts to wake the scheduler for the FE310 and the K210 RISC-V chips.
Depends on #1220
Also somewhat related: https://github.com/tinygo-org/tinygo/blob/04d097f4eaf6682e4f80758e7d0e207ae248b03f/src/runtime/arch_tinygoriscv.go#L84-L90 Isn't this blocking forever since we are waiting for an interrupt with interrupts disabled?
No. The interrupt is masked, so it will not run immediately. Instead what happens is the wfi finishes when the interrupt is pending, then interrupts are re-enabled, then the interrupt executes.
@jaddr2line All right but then shouldn't the riscv.DisableInterrupts() disable interrupts on the global mstatus level because according to the specification page 41:
The WFI instruction can also be executed when interrupts are disabled. The operation of WFI must be unaffected by the global interrupt bits in mstatus (MIE/SIE/UIE) [...] but should honor the individual interrupt enables (e.g, MTIE) (i.e., implementations should avoid resuming the hart if the interrupt is pending but not individually enabled)
Because right now we disable interrupts in the lower individual interrupt enable register: https://github.com/tinygo-org/tinygo/blob/04d097f4eaf6682e4f80758e7d0e207ae248b03f/src/device/riscv/riscv.go#L25-L37
But maybe I understand this wrong.
@jaddr2line I will make some tests when I have time, to check if interruptions wake the scheduler as expected.
Please make sure you rebase against dev that might get rid of the current build errors.
So, I don't think this is actually safe at this point. Right now, the coroutines implementation may end up with a goroutine suspending in the middle of a critical section due to how returns are implemented. In order to make this safe, we need to modify the coroutine task implementation to loop until it is actually fully suspended.
@deadprogram I will do that thanks.
@jaddr2line So it should be safe once #1220 gets merged right?