Hacker News Reader

Comment by joshumax | Hacker News Reader

I stumbled across WasmJIT about a year ago and actually used many of the concepts in the project for my own kernelspace implementation of the portable native client (pNaCl). Projects like these are extremely interesting to me because they offer the possibility of a completely architecture-neutral userspace that can be used across multiple devices without recompilation.

View on HN

This goes a step further and could offer an architecture-neutral kernel space. If part of loading the module includes validation and external memory access is checked as in browser implementations this could even lead to safer/less exploitable kernel modules with more well-defined failure modes.

The problem I see with this is that there are still no 8bit or 16bit data types (or bitfields for that matter) in the wasm spec, which are kind of useful for interfacing with hardware and for protocols (Ethernet, TCP/IP, etc). Sure, you can pack and unpack them with masks and shifts (which I assume clang,LLVM,gcc,etc do), but it seems awfully inefficient when the resulting code ends up running on x86 or other architectures with native 8/16 bit instructions.

Unless I'm missing something, this should be pretty easy for the webassembly working group to fix. At a guess they probably just need some clear decisions around how to handle endian issues. But right now they're just focussing on the browser use case.

If kernel module developers become a vocal part of the wasm ecosystem, I'd expect 8- and 16- bit data types to get added before long.

I wonder if the pattern is common enough and simple enough that wasmjit could substitute the load-shift-and/shift-or-store sequences into direct 8,16,32-bit stores and loads.

> they probably just need some clear decisions around how to handle endian issues

They are handling endian issues by simply requiring little-endian.

Wasm has efficient 16/8 byte load/store instructions. 16/8 bit data types are irrelevant on x86 since it internally uses 32 bit registers anyway.

Huh? x86/x86_64 has segmented registers that can be used as 64 bit (rax), 32 bit (eax), 16 bit (ax), and the upper and lower 8 bits of the latter (ah,al). Not to mention I/O ports which use 16 bit addresses and allow for 8, 16, and 32 bit accesses, and various internal processor data structures that have 8 or 16 bit wide fields, among other uses.

Performing operations using the segmented registers is no faster than using the 32-bit analogues. Benchmark an add of eax,edx vs Al,dl in a loop.

Projects like these are extremely interesting to me because they offer the possibility of a completely architecture-neutral userspace that can be used across multiple devices without recompilation.

It makes one wonder what would have happened if the Micro/370 had gone forward and the architecture-neutral userspace had evolved in the PC space.

http://www.cpushack.com/2013/03/22/cpu-of-the-day-ibm-micro-...

Reply on news.ycombinator.com