That's something I've wanted to do for a long time, but not found the time to do!
On Saturday, March 14, 2026 at 4:37:55 PM UTC-7 Nuno Cruces wrote: > For the past few weeks I've been working on a Wasm to Go > <https://github.com/ncruces/wasm2go> translator. It takes a Wasm module > and converts it to a Go package. I plan to use it for my SQLite driver. I'm > translating a Wasm build of SQLite into ~ 600 kLoC of Go > <https://github.com/ncruces/go-sqlite3-wasm>. I've tested it across 20 > GOOS/GOARCH combinations. > > I have found that GC produces suboptimal code in some situations. > > Wasm is a little endian platform, so a memory load is something like > (offset is a constant literal): > > int32(binary.LittleEndian.Uint32(m.Memory[int64(ptr)+offset:])) > > I've noticed that, on little endian platforms, this works much faster: > > *(*int32)(unsafe.Pointer((*[4]byte)(m.Memory[int64(ptr)+offset:]))) > > I think because the first version has 2 bounds checks, and the later just > one? This is unfortunate, as I have to generate 2 versions of the code (for > little and big endian). > > Am I missing any trick to get the compiler to generate better code? > > Thanks! > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/e0302e6a-57b4-461c-8720-d47048f3e98an%40googlegroups.com.
