This is an alternative to #12241 that uses less bytes (8) to encode the jump.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.44%. Comparing base (46d8db8) to head (8b35f2c).
Report is 1 commits behind head on master.

@@           Coverage Diff           @@
##           master   #15812   +/-   ##
=======================================
  Coverage   98.44%   98.44%           
=======================================
  Files         163      163           
  Lines       21296    21296           
=======================================
  Hits        20964    20964           
  Misses        332      332           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

This looks nice and simple. I will test it later. Probably the -2 adjustment of the offset is what I missed when I tried to implement this.

This function must return the same number of bytes for the encoding of the jump regardless of the value of entry.

As it stands, the function does not obey this property - it's either 2 or 4 bytes. As you mentioned in the review of my code, this can cause issues because the length of instructions is used else where to compute the layout. Is the plan to skip the conditional and always do the long jump (once verified)?

As it stands, the function does not obey this property - it's either 2 or 4 bytes

No, it always emits 8 bytes. See the struct.pack("<HHHH", ...) at the end of the function. There is no other return in the function.

I have run this change with wasm2mpy tests (with and without forcing long jumps) and noticed no regressions.
Coremark builds fine, but still doesn't run properly due to unknown reason.

As it stands, the function does not obey this property - it's either 2 or 4 bytes

No, it always emits 8 bytes. See the struct.pack("<HHHH", ...) at the end of the function. There is no other return in the function.

You are right, of course. I do not know where my head was at.

Tested with a module that exceeds the 2k limitation (before this commit, fails with AssertionError: 3295 in assert b_off >> 11 == 0 or b_off >> 11 == -1, b_off). Builds successfully and looks to run ok on a RPI Pico. So I think this is good to go @dpgeorge !

Thanks @jonnor and @vshymanskyy for testing and review!