Browse thread
Using OCaml's run-time from LLVM-generated native code
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jon Harrop <jon@f...> |
| Subject: | Re: [Caml-list] Using OCaml's run-time from LLVM-generated native code |
On Sunday 03 February 2008 21:24:12 Alain Frisch wrote:
> Jon Harrop wrote:
> > This raises several questions for me:
> >
> > . Is this even possible?
>
> Yes. How could it not be possible? Run your example through cpp, you'll
> get a ``self-contained'' C program that uses only functions exported
> from OCaml's runtime.
How does OCaml's stack walker work with C code, for example? In particular,
how does it know what is a pointer into the heap from a C stack frame? Must
it be explicitly disabled?
I assume local variables must be explicitly registered as global roots upon
entry to each function and unregistered upon exit. If so, what are the
performance implications of this?
I tried and failed to write such an example myself. Here's "forstr.ml":
let print_stat() =
let stat = Gc.stat() in
Printf.printf "%d minor collections\n%!" stat.Gc.minor_collections;
Printf.printf "%d major collections\n%!" stat.Gc.major_collections;
Gc.print_stat stdout
let _ = Callback.register "gc_print_stat" print_stat
let _ = Callback.register "gc_full_major" Gc.full_major
Here's "str.c":
#include <stdio.h>
#include <string.h>
#include <caml/mlvalues.h>
#include <caml/alloc.h>
#include <caml/memory.h>
#include <caml/fail.h>
#include <caml/callback.h>
#include <caml/custom.h>
#include <caml/intext.h>
value *full_major, *print_stat;
CAMLprim value fib(value nv) {
int64 n = Int64_val(nv);
return (n < 2 ? nv : copy_int64(Int64_val(fib(copy_int64(n-1))) +
Int64_val(fib(copy_int64(n-2)))));
}
int apply(int n) {
return Int64_val(fib(copy_int64(n)));
}
int main(int argc, char* argv[]) {
caml_main(argv);
print_stat = caml_named_value("gc_print_stat");
full_major = caml_named_value("full_major");
printf("%d\n", apply(argc == 2 ? atoi(argv[1]) : 10));
callback(*print_stat, 0);
callback(*full_major, 0);
callback(*print_stat, 0);
return 0;
}
Compile and run with:
$ ocamlopt -dtypes -output-obj forstr.ml -o forstring.o && gcc -Wall -o test
forstring.o str.c -L/usr/lib/ocaml/3.10.0 -lasmrun -ldl -lm && time ./test 30
832040
369 minor collections
0 major collections
Segmentation fault
real 0m0.361s
user 0m0.344s
sys 0m0.004s
So this is several times slower than native ocamlopt-generated code, as you
might expect, but it doesn't work correctly because it segfaults when
full_major is called to invoke the GC. How can I fix this example?
If I can get simple examples like this working as C code then it should be
trivial to generate them using LLVM at which point you've got a mediocre
compiler than can be built upon. I think a lot of people would be interested
in that...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e