Altering the control flow of a program in a goto fashion (also from ISRs)

[MarcelKr]

I'm currently developing a python module in C and I need to implement a custom goto function. Once goto is called, the respective function shall be called and it's expected that the control flow never comes back to the calling location. If there's no goto in a function, the program shall terminate. To not fill up the stack, I came up with a "dispatcher" concept.

import mymod

def my_func_3():
    print('X')

def my_func_2():
    print('a')
    mymod.goto(my_func_3)
    print('b')

def my_func_1():
    print('1')
    mymod.goto(my_func_2)
    print('2')

mymod.run(my_func_1)

In the example code, run implements the dispatcher and executes the my_func_1. When a goto is encountered, the function to go to is stored in a variable and a custom exception is raised. The exception is handled in run by calling the desired function.

The output of the program above would be 1 a X. my_func_3 doesn't set a goto and therefore the run function finishes and the program ends.

There's a thread in the old forum talking about this and the suggestion is also to use exceptions. However it's not addressing the problem described in the next chapter.

The Problem: IRQs/Callbacks

Now comes the problem: I want to have callbacks to respond to events. Callbacks being functions executed from another thread than the thread which runs the python "main loop". And these callbacks shall also be able to use goto and alter the control flow of the program.

Here's the example from above expanded by an event registration and callback function:

import mymod

def my_func_2():
    print('X')

def button_func():
    print('a')
    mymod.goto(my_func_2)
    print('b')

def my_func_1():
    mymod.set_callback(ButtonEvent(...), button_func)
    print('1')
    ### ButtonEvent happens here triggerd from other task ###
    print('2')
    mymod.sleep(1)
    print('3')
    mymod.goto(chapter_4)
    print('4')

mymod.run(my_func_1)

The expected output of this program would be 1 a X. Note that - as before - at no point we're returning to my_func_1 or button_func. The control flow shall be completely altered.

Idea 1: Exception in a custom ISR

One idea to solve this was to implement a custom IRQ handler (similar to mp_irq_handler) to store the function to go to and throw an exception. The problem is that exceptions from ISRs are not handed to the main loop.

I assume there's no way to be able to raise exceptions in ISRs and handle them in the main loop (due to register manipulation I assume?!)?

Idea 2: Similar to AsyncIO

Similar to Idea 1, the ISR stores the function to go to but it doesn't do more. The other functions of my module all check if a goto is needed and then throw the exception. Meaning: Exceptions are only thrown in the main loop and therefore can be handled by run. This is similar to asyncIO I think (e.g. it also only aborts tasks on async functions and not builtins etc.)

I already implemented this approach and it works. However obviously the implication is that builtins or other module's functions get executed until encountering one of the mymod functions.

The output of the program above would be 1 2 a X (instead of the desired 1 a X).

Idea 3: Hacking the runtime

Of course "hacking" the runtime is a possibility but I wouldn't be in favor of that (and I'd have no idea about where to start).

The Question: Other ideas?

Is there any other approach you could think of to solve this problem? Or any way of tweaking Idea 1 to meet the desired behavior?

[andrewleech]

micropython.schedule() is already kind of like a goto if you follow it with a raise Exception that's caught and ignored at the top level.

[GitHubsSilverBullet]

Sorry if this sounds a bit harsh, but I'm reminded of the good old 1970s. Where an uncountable number of GOTOs in a BASIC program was the ultimate solution.
Nowadays, using goto more often than not is an indicator that the program needs some more thought.

Why not run an outer loop and call separate functions which return with an indicator-return-value that is used as a decision for the next function to call?

[MarcelKr]

micropython.schedule() is already kind of like a goto

@andrewleech So what you're saying is that in the ISR, I should schedule a function raising an exception to alter the flow of the main loop?

Or maybe the problem statement was not clear enough. My current approach without considering IRQs (= another thread executing the callback) already works. My problem is when wanting to alter the control flow of the main program loop from the ISR (in my example above, the ISR would be the button_func)

@GitHubsSilverBullet yeah, I know it sounds weird but I'm not the one making the requirements :D

Why not run an outer loop and call separate functions which return with …

Yeah, that's what I'm doing and this works well as long no IRQs come into play

[andrewleech]

I mean that an irq can schedule any function to run, the main loop will kind of run it separately, outside the current main call stack.

The comment about raising as exception is more about if you're wanting to jump from non -irq code to somewhere without "continuing" code from the calling function. It's a way to break out of the current call stack.

[MarcelKr]

OK got it. As I'm in C-Bindings-World, I found mp_sched_schedule() and mp_sched_exception(). Calling mp_sched_exception() from the ISR seems like exactly what I need. As I understand mp_handle_pending() is regularly called by the VM to handle whatever I scheduled. See this excerpt:

// Called periodically from the VM or from "waiting" code (e.g. sleep) to
// process background tasks and pending exceptions (e.g. KeyboardInterrupt).
void mp_handle_pending(bool raise_exc) {

However that's not happening for whatever reason. I'm currently using a debugger to understand why and my current understanding is that in vm.c in the main VM loop (MICROPY_WRAP_MP_EXECUTE_BYTECODE()), the goto label pending_exception_check is never jumped to. As far as I understand, it should be jumped to on executing various opcodes by calling DISPATCH_WITH_PEND_EXC_CHECK(). See the following excerpt which shows three of a few more cases:

ENTRY(MP_BC_JUMP): {
    DECODE_SLABEL;
    ip += slab;
    DISPATCH_WITH_PEND_EXC_CHECK();
}

ENTRY(MP_BC_POP_JUMP_IF_TRUE): {
    DECODE_SLABEL;
    if (mp_obj_is_true(POP())) {
        ip += slab;
    }
    DISPATCH_WITH_PEND_EXC_CHECK();
}

ENTRY(MP_BC_POP_JUMP_IF_FALSE): {
    DECODE_SLABEL;
    if (!mp_obj_is_true(POP())) {
        ip += slab;
    }
    DISPATCH_WITH_PEND_EXC_CHECK();
}

As I have no idea how my python code is translated into opcode, further understanding is hard. Do you have any idea why the opcodes which trigger pending exceptions are not executed?