There's no x86_64 VM to test on yet, so obviously the support is only theoretical.
Removing the option of executing emitted bytes in the first place in any x86_64 VM released, just makes that a self-fulfilling prophecy.
There *are* tests that correct x86_64 instructions are emitted for a large number of operations, but by no means all of them.
In other words, emitting x86_64 machine code with a sane Smalltalk API is a use case already somewhat supported (imho).
There's a chicken-and-egg kind of the problem; you don't even want to start coding NB support before you have a platform to run on; which again means, you *cannot* rely on it to get a base image up and running. After Spur images are actually released, creating support for interacting with the new image format / VM probably probably wouldn't be too much work, nor getting x86_64 to a better state wrt. emitting correct instructions.
Though, I guess for the worried, in order to have it included in a general release, you would need to rewrite the NB primitive to
- Provide validation along the lines of NaCl
- Store/Execute validated machine code in/from a restricted space, rather than in method trailers
which means none of the above will ever happen.
The main pain points in image-side programming are support for other instruction sets to the same level of completeness as AsmJIT is for x86/x64, and implementing new ABI's for FFI (which, after all, is what *most* people seem to use NB for).
All of which add up to making Sista bytecodes a less exiting, but more reasonable alternative.
Cheers,
Henry