caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@ffconsultancy.com>
To: Alain Frisch <alain@frisch.fr>
Cc: caml-list <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Using OCaml's run-time from LLVM-generated native code
Date: Mon, 4 Feb 2008 10:32:05 +0000	[thread overview]
Message-ID: <200802041032.05929.jon@ffconsultancy.com> (raw)
In-Reply-To: <47A6B8B5.9010907@frisch.fr>

On Monday 04 February 2008 07:03:17 Alain Frisch wrote:
> Jon Harrop wrote:
> > 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?
>
> The OCaml runtime does not scan the stack frames corresponding to C
> functions.

How does it know which stack frames correspond to C functions?

> Jon, it is somewhat weird that you spend so much time writing about
> forking OCaml and do not take a few minutes to read the source code. The
> macros CAMLparam*, CAMLlocal* are not really that mysterious.

Despite the availability of that code it seems that few people can use it 
correctly and I am one of them.

This seems to work even though it calls full_major aggressively:

#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>

extern value caml_gc_full_major(value v);

CAMLprim value fib(value nv) {
  CAMLparam1(nv);
  CAMLlocal5(a, b, c, d, e);
  int64 n = Int64_val(nv);
  if (n < 2) CAMLreturn(nv);
  a = copy_int64(n-1);
  b = copy_int64(n-2);
  c = fib(a);
  d = fib(b);
  e = copy_int64(Int64_val(c) + Int64_val(d));
  caml_gc_full_major(0);
  CAMLreturn(e);
}

int apply(int n) {
  CAMLlocal2(nv, fibn);
  nv = copy_int64(n);
  fibn = fib(nv);
  caml_gc_full_major(0);
  return Int64_val(fib(nv));
}

int main(int argc, char* argv[]) {
  caml_main(argv);
  printf("%d\n", apply(argc == 2 ? atoi(argv[1]) : 10));
  return 0;
}

Is that correct code?

Rather than messing around with these macros in each and every function it is 
probably easier and more efficient to register a single global root at entry, 
pointing to a shadow stack and push and pop elements to and from that 
directly.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e


  reply	other threads:[~2008-02-04 10:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-01 21:24 Jon Harrop
2008-02-03 21:24 ` [Caml-list] " Alain Frisch
2008-02-03 23:19   ` Jon Harrop
2008-02-04  7:03     ` Alain Frisch
2008-02-04 10:32       ` Jon Harrop [this message]
2008-02-04 11:11         ` Alain Frisch
2008-02-04 13:36           ` Jon Harrop
2008-02-04 15:20             ` Alain Frisch
2008-02-05 23:08             ` Florent Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200802041032.05929.jon@ffconsultancy.com \
    --to=jon@ffconsultancy.com \
    --cc=alain@frisch.fr \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).