> On 16 Dec 2015, at 6:48 , Clément Bera <[email protected]> wrote: > > > > 2015-12-15 20:22 GMT+01:00 Jan Vrany <[email protected] > <mailto:[email protected]>>: > Hi Esteban, Eliot, Clemont > > thanks very much for elaborate answer. I'm aware of all what you said > (well, most :-), but my actual needs are very low and primitive. > > All I need now is something that allows me to turn x86_64 assembly > into a machine code using a sane Smalltalk API, which I can later copy > to VM code space. Nothing more, nothing less :-) I do not fancy > spending time writing yet-another-x86-assembler hence my interest in > asmjit. > > As far as I know AsmJIT has stable support for x86 but not x86_64
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
signature.asc
Description: Message signed with OpenPGP using GPGMail
