Computed goto for efficient dispatch tables (2012)

(eli.thegreenplace.net)

19 points | by firephox 3 days ago

4 comments

  • jdw64 42 minutes ago
    I understood up to the comparison operations in this article, but I'm having trouble understanding branch prediction even after reading it. It seems like they used branch prediction optimization... Sometimes when I read articles like this, I start to question whether I can really call myself a programmer
  • nly 1 hour ago
    All well and good provided your opcodes are sequential/dense
    • adrian_b 1 hour ago
      The same is true for a "switch" statement.

      If the "case" values used in a "switch" are sparse, the "switch" will not be compiled into an indexed jump instruction, but into a sequence of conditional jump instructions, which test all the possible cases.

      In this situation, the alternative to "switch" for implementing dispatching is no longer a computed "goto", but a multiple "if"/"else" sequence.

      A smarter compiler could detect when a "switch" forms the body of a loop and it would replicate the indexed jump instruction at the end of each case, instead of jumping to the beginning of the loop to execute there an indexed jump, or even worse, first jumping to the end of the loop to terminate the "switch", then jumping to the beginning of the loop to repeat the loop body.

      With such a compiler, computed "goto" would not be necessary as an alternative to "switch".

      The range check inside the dispatch loop would not be necessary if the opcodes had an enumeration type (in a programming language where enumeration types are clearly distinct from integers) and the "switch" handled all the possible cases. In that situation, the range checks would be moved elsewhere in the program, wherever opcodes are generated.

  • froh 1 hour ago
    (2012)