Pretty much everything is on incoming, including SIMD, I can't think of a major feature that isn't.
On Fri, Aug 28, 2015 at 12:27 AM, <[email protected]> wrote: > Oh, thanks! Did not know that pthreads already made it into incoming. Is > everything always in incoming, such as also the SIMD branch? > I'll try your suggestions. > Thanks! > > Am Donnerstag, 27. August 2015 22:45:40 UTC+2 schrieb Alon Zakai: >> >> pthreads has already been merged to incoming, so you can use that. >> (Unless there is another pthreads branch I'm not aware of?) >> >> I believe dlsym should work on the same process, on a main module. Not >> sure, if not, please file an issue. >> >> On Thu, Aug 27, 2015 at 12:30 PM, <[email protected]> wrote: >> >>> I am basing my work on juj's pthreads branch, since I need threading >>> more than I need dynamic linking. And I think, juj's pthreads branch does >>> not contain support for dl functions? >>> Also, can I use dlsym to lookup symbols in "this" process, instead of in >>> a shared library? >>> >>> Thanks! >>> >>> Am Donnerstag, 27. August 2015 02:22:26 UTC+2 schrieb Alon Zakai: >>>> >>>> Why not use dlsym? An emscripten shared module (SIDE_MODULE=1) has the >>>> semantic information to map function names to function pointers. You can >>>> also use it directly without dlsym if you prefer, the module basically >>>> returns a object that maps symbol names to values (and for a function, the >>>> value is a function pointer). >>>> >>>> Once you have the function pointer, you can then call it. Use >>>> Module.dynCall_* where * is the type. Again, looking at the output of a >>>> shared module might be the easiest way to see how this can work. >>>> >>>> On Wed, Aug 26, 2015 at 12:05 PM, <[email protected]> wrote: >>>> >>>>> Hi Alon, >>>>> >>>>> thanks for answering. Sorry, it has been a while since I attacked this >>>>> problem. >>>>> Now, I give it another try. >>>>> >>>>> So, please let me explain my concrete problem: >>>>> >>>>> My concrete problem is that a language unlike C/C++ or any other >>>>> language that can be compiled via Emscripten, in particular that language >>>>> is Java, uses a mechanism called "Java Native Interface" to declare and >>>>> link to native functions at runtime. >>>>> Concretely those native functions are themselves implemented in C in >>>>> the gnu classpath library and are compiled and archived via Emscripten >>>>> into >>>>> .a files. >>>>> This process works perfectly with Emscripten! >>>>> But, the process of invoking that function is not from C and does not >>>>> have function prototypes/signatures to compile against. >>>>> The Java Virtual Machine, while interpreting the Java bytecode files, >>>>> sees that a "native" method is about to be invoked. >>>>> Then, it looks up the pointer to the corresponding native function >>>>> (question: "how do I lookup a native function dynamically with Emscripten >>>>> at runtime without using dlsym and all the dynamic library features?"). >>>>> After the native function was found, the arguments are being put on >>>>> the C stack via some mechanism (in a desktop JRE this is done via x86 >>>>> assembly code or the libffi), and then the function is called through the >>>>> function pointer. >>>>> Now, my question is concretely: How would I achieve this? I know how >>>>> to link everything in a static library, as one should do that with >>>>> Emscripten. But now I do not know how to lookup the pointer to a function >>>>> in the process and how to pass arguments from C to its JavaScript "native" >>>>> function. >>>>> >>>>> Thanks! >>>>> Kai >>>>> >>>>> Am Montag, 4. Mai 2015 21:45:31 UTC+2 schrieb Alon Zakai: >>>>>> >>>>>> Maybe I wasn't understanding you before. A concrete code sample might >>>>>> help. >>>>>> >>>>>> - Alon >>>>>> >>>>>> >>>>>> On Thu, Apr 30, 2015 at 2:13 PM, <[email protected]> wrote: >>>>>> >>>>>>> Thank you for your answer! >>>>>>> >>>>>>> Although I am totally not getting anything from that 19 lines of >>>>>>> test case and how anything is supposed to work with that, let alone what >>>>>>> that test case is actually doing. Looks very cryptic to me. :) >>>>>>> But if you say it's gonna work this way, then I will try further. >>>>>>> >>>>>>> I just don't know how it can be possible to invoke a function whose >>>>>>> signature I cannot express in C code at compile time with a prototype, >>>>>>> since the actual signature is encoded via some other mechanism as a >>>>>>> string >>>>>>> that I can query at runtime, such as "(II)V", meaning "take two integers >>>>>>> and return void". >>>>>>> >>>>>>> And I don't know how to put arguments from the emscripten HEAP on >>>>>>> the C stack and call that function then. >>>>>>> >>>>>>> dlfnc symbols seem to be needing a compile-time function prototype >>>>>>> to cast against before invoking the function. >>>>>>> But I don't have that. And I think that's also the problem that >>>>>>> libffi is solving with all that assembler magic, because one has no >>>>>>> function prototype/signature at compile time. >>>>>>> >>>>>>> So the original question was whether it would then make more sense >>>>>>> to generate asm.js code during runtime which is able to decode the >>>>>>> signature string (i.e. the "(II)V") of the function into a real >>>>>>> JavaScript >>>>>>> function invocation. >>>>>>> >>>>>>> Thanks again! >>>>>>> >>>>>>> Am Samstag, 25. April 2015 10:26:53 UTC+2 schrieb >>>>>>> [email protected]: >>>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> I was wondering what would be a possible solution to dynamically >>>>>>>> call an Emscripten-compiled function within the same application (no >>>>>>>> dynamic library). >>>>>>>> The issue is that during compile-time I do not know the target >>>>>>>> function's signature and therefore do not have static C caller code >>>>>>>> that >>>>>>>> could invoke the required function, but must instead build such code >>>>>>>> during >>>>>>>> runtime. >>>>>>>> >>>>>>>> For native languages there exists libffi for exactly this purpose >>>>>>>> and it is using assembler code to put function arguments on the stack. >>>>>>>> I was wondering what the best approach with emscripten is to link a >>>>>>>> dynamic function call to its target function. >>>>>>>> The information I have at a possible caller-site is: (function >>>>>>>> name, function signature, base stack pointer on the heap of the first >>>>>>>> argument). >>>>>>>> I was thinking about dynamically building a small asm.js module >>>>>>>> which reads the arguments from the heap starting at the base pointer >>>>>>>> and >>>>>>>> which then builds an appropriate function call. >>>>>>>> This script I would then eval() in order to get an asm.js-compiled >>>>>>>> libffi-like interface. >>>>>>>> >>>>>>>> Would this be a viable approach? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Kai >>>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "emscripten-discuss" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "emscripten-discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
