|
|
Log in / Subscribe / Register

Bounded loops in BPF programs

Bounded loops in BPF programs

Posted Dec 5, 2018 23:30 UTC (Wed) by wahern (subscriber, #37304)
In reply to: Bounded loops in BPF programs by roc
Parent article: Bounded loops in BPF programs

The Relooper algorithm isn't much better, if at all. Per the original paper, Emscripten: an LLVM-to-JavaScript compiler:

In general though, this is not always easy or even practical – there may not be a straightforward high-level loop structure corresponding to the low-level one, if for example the original C code relied heavily on goto instructions. In practice, however, almost all real-world C and C++ code tends to be amenable to loop recreation.

Of course "almost all" code is amenable because very little code comprises the more critical, performant inner loops and state machines--the parts which often heavily rely on goto.

Arguably if JavaScript had goto there likely never would have been a need to create and rely on the Relooper, and WebAssembly may have turned out differently. Lua 5.2 added a goto construct precisely because it made code generation so much easier. I suspect that eventually much BPF code will be generated from high-level DSLs. Not everybody will be using the same toolchains and libraries, and not having a goto construct is a serious headache when machine generating code. Generating performant assembly from a task-specific, declarative DSL is often trivial; much less so if you now need to implement a relooper or integrate a relooper library.

WebAssembly was originally envisioned as a simple, pure stack-based VM where variable scoping and structured blocks naturally aligned with the overall design. A goto construct was unfathomable. But then WebAssembly got much more complex and the simple stack-based design fell away. I suspect adding a goto construct could have been possible after the original, simpler concept gave way, and I wouldn't rule out its addition in the future. Gotos (including computed gotos) are still very useful in performant C code because optimizing compilers still can't do the job--in real-world code the best switch-statement optimizations still can't come close to idiomatic use of gotos and computed gotos. Like with JIT compiling, microbenchmarks and theoretical optimizations never quite make the transition to the real-world undiminished. Performance demands may still necessitate goto.


to post comments

Bounded loops in BPF programs

Posted Dec 6, 2018 0:30 UTC (Thu) by wahern (subscriber, #37304) [Link] (1 responses)

> WebAssembly was originally envisioned as a simple, pure stack-based VM where variable scoping and structured blocks naturally aligned with the overall design.

What I had in mind here was the transition from the AST-based bytecode format to the structured stack machine format. The transition shifted WASM in the direction of a model where you could contemplate adding gotos. The transition happened because implementations were *already* using modern compiler techniques, like SSA transforms. Adding a goto construct with a sophisticated verifier is much less of a leap than when your machine model is based directly on ASTs.

For more context see https://github.com/WebAssembly/design/issues/755 and https://docs.google.com/document/d/1CieRxPy3Fp62LQdtWfhym...

Bounded loops in BPF programs

Posted May 12, 2019 11:16 UTC (Sun) by ibukanov (subscriber, #3942) [Link]

One of design goals of WebAssembly was fast verification to minimize loading time. Explicit goto significantly increase complexity of the verifier.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds