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% PICO
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

Codecov Report

Merging #11887 (3474a65) into master (813d559) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master   #11887   +/-   ##
=======================================
  Coverage   98.41%   98.41%           
=======================================
  Files         155      155           
  Lines       20564    20564           
=======================================
  Hits        20238    20238           
  Misses        326      326           

Out of interest: how did you get the asm code? Is it from the disassembly of the msvc setjmp implementation? It looks rather similar but that's no surprise, after are there's only so many ways to do this. Just for reference it's shown here #4652). That being said: since setjmp is available and works it's not clear to me what we're gaining by switching to a custom implementation.

Out of interest: how did you get the asm code?

I wrote it from first principles, basing on the existing code in mpy but adapting it to MS calling conventions. Never looked at MSVC code. Since custom asm NLR seems to be available and used for most targets on gcc/clang, I thought perhaps it wouldn’t be a bad idea to get it done for MSVC too.

This is a first step toward getting native code emitters - at least for Intel - working on MSVC (already done just needs to be cleaned up). Thinking about it now, perhaps I should bite the bullet and get ARM NLR and native emitter working user MSVC too.

Turns out Windows NLR handling will also need SEH state to be preserved.

So this is a draft at the moment. I'll investigate whether the setjmp/longjmp implementation is sufficient.