One should really note the major differences dynasm took from the more abstract and logical jit libraries, which try to abstract platform oddities from the user. Like LLVM, libjit, asmjit, v8, libgccjit, lightning or nanojit.
It doesn't care how you call a function, it doesn't even care about 2 or 3 address op syntax. All it does is adding simple template logic to let you handle the platform-specific abstractions by yourself.
And in the end it's easier to add your own prologue or prepcall1 macro, than relying on a library.
people always looked at the "most portable jit library". dynasm offers no platform support per se, as all the others do. you have to do by yourself. it's the least portable of all. but in the end it was much more powerful, and offered the most ports. you get the asm anyway by dissambling the target function. with the libraries (such as LLVM) you'd need to translate a high-level overview to the library API.
with dynasm you just need to adjust your types, prologue, struct field accesses and epilogue. and dynasm is perfect and practical in doing this, whilst the other libraries try do to much more, with much more handholding and are much bigger and less effective.
I don't agree with the genius part though. lua itself was pretty much perfect already, and lua took most of the good parts from earlier dynamic languages, lisp and self, and esp. Inferno's "Dis VM". http://doc.cat-v.org/inferno/4th_edition/dis_VM_specificatio... which was Lucent's faster and smaller competitor of Sun's stack-based and GC-heavy JVM.
it just missed besides a jit a good OO, and luajit didn't add that neither. e.g. _why the lucky stiff added a nice OO layer on top of lua, plus a nice simple jit. much simplier than luajit.
luajit just objected to some questionable decisions in lua regarding performance, and then took over. esp. nan tagging makes a lot of sense, but the compiler optimizations are also pretty cool. esp. when compared to the massive LLVM overhead.
luajit is using the slower and bigger 3-address SSA and the optimizations based on that. but the CPU and the lua bytecode is just using the fast and natural two address op syntax, where it is not easy to add SSA. This is the genius part. http://wiki.luajit.org/SSA-IR-2.0
Yes, potion. It's a better rewrite of lua, as luajit.
Same op and data layout as lua, just with a simple method jit (luajit does tracing and optimizations), plus a msg send based OO.
It doesn't care how you call a function, it doesn't even care about 2 or 3 address op syntax. All it does is adding simple template logic to let you handle the platform-specific abstractions by yourself.
And in the end it's easier to add your own prologue or prepcall1 macro, than relying on a library.
people always looked at the "most portable jit library". dynasm offers no platform support per se, as all the others do. you have to do by yourself. it's the least portable of all. but in the end it was much more powerful, and offered the most ports. you get the asm anyway by dissambling the target function. with the libraries (such as LLVM) you'd need to translate a high-level overview to the library API. with dynasm you just need to adjust your types, prologue, struct field accesses and epilogue. and dynasm is perfect and practical in doing this, whilst the other libraries try do to much more, with much more handholding and are much bigger and less effective.
I don't agree with the genius part though. lua itself was pretty much perfect already, and lua took most of the good parts from earlier dynamic languages, lisp and self, and esp. Inferno's "Dis VM". http://doc.cat-v.org/inferno/4th_edition/dis_VM_specificatio... which was Lucent's faster and smaller competitor of Sun's stack-based and GC-heavy JVM. it just missed besides a jit a good OO, and luajit didn't add that neither. e.g. _why the lucky stiff added a nice OO layer on top of lua, plus a nice simple jit. much simplier than luajit.
luajit just objected to some questionable decisions in lua regarding performance, and then took over. esp. nan tagging makes a lot of sense, but the compiler optimizations are also pretty cool. esp. when compared to the massive LLVM overhead.
luajit is using the slower and bigger 3-address SSA and the optimizations based on that. but the CPU and the lua bytecode is just using the fast and natural two address op syntax, where it is not easy to add SSA. This is the genius part. http://wiki.luajit.org/SSA-IR-2.0