๐คluu๐9y๐ผ146๐จ๏ธ40
(Replying to PARENT post)
Seems like this would make one able to write the object-code codegen phase of a compiler at a rather higher level (at least if you're only targeting x86, or are willing to write similar libraries for your other arch targets.)
Or, to put it another way: looks like a good library for adding "just a bit of JIT" to an interpreter, without going full LLVM.
๐คderefr๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
"As new instructions are made public"? WTF does that mean? We're not even allowed to know the full instruction set of an X86 CPU?
๐คdreamcompiler๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
This is awesome. I thought it's closed source. I wonder how close it is to the hardware.
Can I assume that whatever is parsed by XED is going to be parsed in the same way by real CPU's?
๐คmajke๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
How does this compare to ARM's VIXL?
๐คstruct๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
About time they open sourced it. Funny how it is Python according to github :)
๐คthecompilr๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
Looks handy. Thanks for posting, Dan.
๐คjonjohn84๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
Something that is universal is not remarkable. People will not make as much use of an unremarkable opportunity as they will of a remarkable one.
๐คdsfyu404ed๐9y๐ผ0๐จ๏ธ0
(Replying to PARENT post)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9932
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9383