WASM + GO

A pure-Go WebAssembly JIT,
no cgo required.

Decode, validate, compile and run wasm through a single-pass x86-64 backend — native machine code from Go, with zero cgo, no C toolchain, no heavyweight runtime.

bash — wago 

    


    

      
      View on GitHub ↗
    

    
linux/amd64 · early-stage · Apache 2.0

  


  
  

    
Install and run.


    

      

        
install

        
$ go get github.com/wago-org/wago

      

      

        
cli

        
$ wago run      fib.wasm 30
$ wago compile  fib.wasm -o fib.wago
$ wago validate fib.wasm

      

    


    

      README →
      CONTRIBUTING →
      ROADMAP →
    

  


  
  

    
We show our work.

    
Tracked against the official WebAssembly/testsuite (pinned MVP-era). The number climbs as we close gaps.


    

      

        

          24/58
        

        
applicable MVP files fully passing

        

        
wasm 1.0 / MVP · updated 2026-06

      

      

        
~7,450

        
assertions passing

        

          PASS
          PARTIAL
          BLOCKED
          FAIL
        

        → read the full SPECTEST.md
      

    

  


  
  

    
Implementation status

    

      ●done
      ◐partial
      ○planned
      ✕not planned
    


    
    

      

        WebAssembly 1.0
        the MVP — core spec, the priority
      

      11 / 17 done
    

    

      
i32 / i64 integer ops● done

      
f32 / f64 arithmetic & compare● done

      
f32 / f64 ceil · floor · trunc · nearest · copysign○ planned

      
conversions + reinterpret● done

      
float→int trunc NaN / overflow trapscomputes, doesn’t trap yet◐ partial

      
control flow · block / loop / if / br / br_table● done

      
call · call_indirect● done

      
select · drop · nop · unreachable● done

      
locals · get / set / tee● done

      
globals · get / set, mutablenumeric; ref/vec rejected● done

      
linear memory load / storei64 sub-width loads pending◐ partial

      
memory.size · memory.grow○ planned

      
active data segments● done

      
tables + active element segments● done

      
function imports / exportshost imports: void, batched● done

      
memory / table / global imports & exportsglobals done; mem/table gaps◐ partial

      
start function○ planned

    


    
    

      

        Post-1.0 & platform
        later proposals + engine/platform reach
      

      0 / 15 done
    

    

      
sign-extension ops○ planned

      
non-trapping float→int · trunc_sat○ planned

      
multi-value results◐ partial

      
reference types · funcref / externrefselect t done◐ partial

      
bulk memory · copy / fill / init○ planned

      
tail calls · return_call○ planned

      
SIMD · v128○ planned

      
threads & atomics○ planned

      
synchronous host-import results○ planned

      
WASI preview 1○ planned

      
targets beyond linux/amd64arm64 · macOS · Windows○ planned

      
multi-memory✕ not planned

      
exception handling✕ not planned

      
garbage collection · wasm GC✕ not planned

      
interpreter tierJIT-only by design✕ not planned

    

  


  
  

    
From bytes to native.

    
wago runs native code on an off-heap foreign stack with mmap-backed linear memory exposed directly as a Go []byte. It borrows its host-boundary shape and runtime ABI from WARP, then keeps the Go side intentionally small and dependency-free.


    
    

      Today
      ● single-pass JIT — shipping
    

    

      

        

          
decode

          
.wasm bytes

        

        
→

        

          
validate

          
type-check

        

        
→

        

          
single-pass

          
x86-64 codegen

        

      


      
↓


      

        

          
mmap'd JobMemory

          

            
basedata

            
linear memory → Go []byte

          

        

        

          
foreign-stack exec

          
native code, off-heap stack, no cgo

        

      


      
↳ host-boundary shape & runtime ABI derived from WARP — a stable wrapper ABI is generated for every export.

    


    
    

      Planned
      ○ an IR, with room for more codegen stages
    

    

      

        

          
decode · validate

          
shared front end

        

        
→

        

          
lower to IR

          
typed, target-agnostic

        

        
→

        

          
opt passes

          
dce · fold · regalloc

        

      


      
↓

      
one IR — many backends


      

        

          
single-pass x86-64

          
● shipping — becomes one backend

        

        

          
optimizing x86-64

          
○ planned — fed by the IR

        

        

          
arm64 · macOS · Windows

          
○ planned — new target backends

        

      


      
↳ An IR decouples the front end from codegen: today's single-pass x86-64 becomes one backend among several, with optimization passes and new targets slotting in behind the same typed IR. Directional — not yet built.