On 10/1/2012 1:26 AM, Mark Roos wrote:
From Charles
Have you taken a look at jnr-x86asm?
No, but I just bookmarked it to talk a look. I had been looking at
JNA as a way to connect to native
libs. Is there some way for me to locate/search for the jRuby native
handler code that uses jnr?
I was looking at LLVM with the thought of optimizing the code I
generate on the fly. Perhaps some
fairly large sets. The idea would be to generate a 'static' Smalltalk
using the PIC information on types.,
convert it to C and then give it to LLVM to work over. The other area
I am concerned about it the GWT
for large or specialized ( integer ) callSites. This is much more
limited and may be a good spot for jnr.
In the later case I would be more concerned about the JNI overhead
this reminds me of something, don't know if relevant (this may be a
tangent, sorry in advance):
has anyone really considered basically writing a tool to read C headers
and uses automatic code generation for most of the cross-language gluing?...
in my case, I am doing something like:
tool reads C headers, and spits out a database of everything it sees;
when FFI magic is needed by the VM, it fetches the metadata from the
databases, spits out any intermediate machine code, and uses this to
interface with the native code.
a partial issue (making this less convenient for the JVM) is that there
is no good (Java-side) mechanism for linking against the native code
(apart from ugly hackery, like making an entire C-land library or header
pose as a synthetic class...).
in my script language, the script-level interface is done via constructs
like "native import C.whatever;", and "native package C.whatever".
"native import" is used to import things from C land. in this case, it
imported a "package", which could contain functions directly. a Java
adaptation would more likely need to treat it as a synthetic class (say,
the compiler reads the database, and pretends that the class in question
exists).
(possibly, a physical class-file could be generated, containing
signatures for those methods which were accessed, the main alternative
probably being putting the database into the JAR).
"native package" is used to export APIs to C (a tool was used to handle
the C-side API exporting, basically spitting out a header and some
trampoline functions and similar to handle calls back into the VM code).
basically, marking it "native" is an "export this stuff" hint to the tools.
I like my mechanism, mostly because it (along with a few other
features), allows making it easier to largely ignore the split between
the code running inside and outside the VM (because I am lazy and don't
like having to write boilerplate to do cross-language calls or data
sharing). (I like to compare it to the ' extern "C" ' mechanism in C++,
where despite there being a cross-language border, it can largely be
ignored for the most part by programmers).
admittedly, I have little idea if similar would be a viable option for
the JVM.
(if anyone actually cares, they can ask me and I can send them the
source for the header-parsing / database-generation tool at least).
or such...
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
