Control flow - Githubissues

almarklein commented 4 years ago

From a high pov:

[x] Support for ternary operations (x = .. if .. else ..)
[ ] ~ternary operations become op_select instead of control flow~ -> too complex
[x] Support for if-statements
[x] Support for for-loops
[x] Support for while loops
[x] Support for quadratic (x**2)
[x] Support for unary operations neg and not.
[x] Support for logical and and or.
[x] Support to return from a fragment shader (i.e. discard fragment).
[x] Support for % modulo operator.

Implementation:

[x] Fix for fact that Python jumps are sometimes inconsistent, making it harder to find where branches merge.
[x] Fix control flow for Python's or to meet requirements of SpirV branching.
[x] Handle using variables across blocks.
[x] Handle non-empty stack between blocks.
[x] Get near 100% test coverage
[x] Get really good test coverage for those or logic. If I make a mistake here, it will cause someone a lot of tears.
[x] Rename co_binop (it feels a bit too shorntened).
[x] Implement _op_jump_if_true_or_pop -> raises an error with a (more or less) friendly error message.
[x] Check todo's that I added in this PR
[x] Maybe turn some todos into issues.

Korijn commented 4 years ago

Just wanted to show my support: this is really impressive :)

almarklein commented 4 years ago

Almost there ...

almarklein commented 4 years ago

sigh in Python 3.8 there have been some changes to the bytecode: The interpreter loop has been simplified by moving the logic of unrolling the stack of blocks into the compiler. The compiler emits now explicit instructions for adjusting the stack of values and calling the cleaning-up code for break, continue and return.

Removed opcodes BREAK_LOOP, CONTINUE_LOOP, SETUP_LOOP [...]

That SETUP_LOOP was really useful for us to tell that a loop was coming, but that info is now gone :'(

Korijn commented 4 years ago

Yeah... it's a risk of relying on internals :(

ivoflipse commented 4 years ago

It may help to ask support from core devs on what opcodes would be best to use, since they may keep changing this even further

almarklein commented 4 years ago

I don't think that's necessary. The loop structure can still be derived from the jumps, and is actually not that much different from what the code does now. It's mostly that the SETUP_LOOP and POP_BLOCK gave us a nice signal, and now we have to evaluate the bytecode a bit harder. I've made a start, and I have a good feeling about it.

almarklein commented 4 years ago

🥳

pygfx / pyshader

Control flow #35