search for: metaocaml

...ry interesting, if you can make it work. The closest example I have heard of is work on metaprogramming (or partial evaluation) by exposing a compiler's parse trees to the programmer, but I suspect that is more limited. I don't know specific references offhand but one of the papers on MetaOCaml (which takes a different approach) may have citations to such work. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Oct 21, 2004, at 3:20 AM, Simon Funk wrote: > Hi, > > I just wrote up a recent project which I think would be a natural > fit with LLVM. I'm...

Hi, I just wrote up a recent project which I think would be a natural fit with LLVM. I'm curious if y'all see this working well or if you can see any gotchas. Also potentially interested in finding someone comfortable with LLVM who would like to collaborate: Executive summary: What if the syntax and semantics of a programming language were specified in a library, rather than built

...VM abilities, ie to use LLVM to generate (eg JIT) code which respect Ocaml GC requirements. Of course, I do know that there are some typing issues and theoritical points which I deliberately ignore here. I'm supposing the guy wanting to LLVM for Ocaml is knowing that he seeks trouble. And Metaocaml is (unfortunately) nearly dead: future (in ocaml 3.11 or 3.12) dynamic libraries ability is not a full replacement! Even if one might generate Ocaml code and compile & dlopen it in a future version of Ocaml. Thanks for reading. -- Basile STARYNKEVITCH http://starynkevitch.net/Basil...

...be exciting to have an Ocaml with "exec" (surely it would > allow new classes of programs), but static compilation seems clearly > superior for existing programs, so my focus is there for now. There are various different approaches to this, of course, but having tried the Lisp and MetaOCaml approaches I think the best way is probably to exploit LLVM's JIT facilities directly. The problem is simply that any abstractions impose significant performance overheads that are large enough to undermine the point of having an "exec" in the first place. So I would not recommend...

...SMC's schedule, and using memory booked to the SMC. Otherwise, this is another DoS vulnerability possible due to improper resource accounting. I was going to ask about SMC in a separate e-mail, but since I brought it up here: can LLVM support languages with SMC or runtime code generation like MetaOCaml? I don't see how it could be done from what I understand of LLVM, but perhaps others see a way. It might be possible with additional intrinsics that invoke the JIT, but I don't see how native LLVM can express SMC. Thanks for your detailed response. Hope I've been able to clear everythi...

On Nov 26, 2007, at 13:27, Basile STARYNKEVITCH wrote: > As some might probably know, the LLVM compiler http://llvm.org/ has > (at least in its latest SVN snapshot) a binding for Ocaml. This > means that one could code in Ocaml some stuff (eg a JIT-ing > compiler) which uses (and links with) LLVM libraries. Yep! There are no bindings for the JIT (just for codegen), but it has

...using memory booked to the SMC. Otherwise, this is another DoS > vulnerability possible due to improper resource accounting. > > I was going to ask about SMC in a separate e-mail, but since I brought > it up here: can LLVM support languages with SMC or runtime code > generation like MetaOCaml? I don't see how it could be done from what > I understand of LLVM, but perhaps others see a way. It might be > possible with additional intrinsics that invoke the JIT, but I don't > see how native LLVM can express SMC. > > Thanks for your detailed response. Hope I've bee...

Sandro Magi wrote: > SVA looks very promising. It would be great to be able to run > unmodified C safely! > > However, it does not seem to address my original question: how can I > ensure that code cannot DoS either the memory subsystem, or the CPU? > To be honest, while I understand your questions, I do not understand the context in which you are asking them. Are you asking

SVA looks very promising. It would be great to be able to run unmodified C safely! However, it does not seem to address my original question: how can I ensure that code cannot DoS either the memory subsystem, or the CPU? In my proposal, I could execute said code in a concurrent process with a memory quota. How would SVA address that problem? Sandro On 6/2/07, Vikram S. Adve <vadve at