similar to: [LLVMdev] ocaml gc support

Hello. In the writing of my OCaml-R binding, I'm sort of confused when it comes to the use of the PROTECT and UNPROTECT macros. Basically, I have C stub functions that are in charge of calling R for everything. Here's a simple example: > CAMLprim value r_findvar (value symbol) { > /* The findVar function is defined in envir.c. It looks up a symbol > in an environment.

>>> On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote: >>> >>> FWIW what I think you should be really looking at is >>> R_PreserveObject/R_ReleaseObject. > > OK. Thanks. >>> I would suggest looking at the many other R embeddings in other >>> languages that already exist since I don't think you approach is >>> very viable

Sorry for the triple-posting! :-$ On 02/14/2013 04:30 PM, Yiannis Tsiouris wrote: > On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: >> After rebasing my local LLVM repo to ToT, I noticed that the >> finishAssembly function is not executed and, thus, the stack map is not >> printed at all. >> >> Is this a known issue or I 'm doing something wrong? >>

On Aug 14, 2007, at 3:24 AM, Gordon Henriksen wrote: > On Aug 14, 2007, at 00:23, Chris Lattner wrote: >> On Mon, 13 Aug 2007, Gordon Henriksen wrote: >>> Changing these structures breaks binary compatibility (including >>> C interop). >> If that is so, and if there is no way around this, then it makes >> sense to develop some compatibility mode. How

Jim Grosbach wrote: > Hi Ali, > > Thanks for bringing this up. You're definitely under very tight design > constraints from the hardware. I can certainly sympathize. Jim, First of all, thank you very much for understanding every detail of the problem at our hand and coming up with a solution that addresses every aspect of it. IMO, given the constraints, this is probably the best

I'm hacking on an llvm backend for the ocaml language. http://caml.inria.fr/ocaml/ I'd like to solicit some advice regarding the constant data structures that ocaml's runtime requires. Rewriting its runtime is a non-goal. The biggest problem is a data structure called the frame table, a simple structure for which LLVM seems ill-prepared. For each call site in the program, ocaml

Ping for this. On 02/10/2013 08:47 PM, Yiannis Tsiouris wrote: > After rebasing my local LLVM repo to ToT, I noticed that the > finishAssembly function is not executed and, thus, the stack map is not > printed at all. > > Is this a known issue or I 'm doing something wrong? > > I used a custom GCMetadataPrinter plugin but I reproduced this using the > builtin

Extended thanks to the llvm community for feedback in advance, and especially thanks to Jim for laying out a solution that captures all aspects of the problems that we are facing. After some discussions with our team, we have decided to do the following, but to avoid further conflict with llvm standards, I would like to get the blessing of llvm community, and in particular, Chris who at some point

On Aug 27, 2009, at 2:02 PM, Alireza.Moshtaghi at microchip.com wrote: > Extended thanks to the llvm community for feedback in advance, and > especially thanks to Jim for laying out a solution that captures all > aspects of the problems that we are facing. After some discussions > with > our team, we have decided to do the following, but to avoid further > conflict with llvm

On Mon, 13 Aug 2007, Gordon Henriksen wrote: >> The table is a contract between the specific codegen you're using and the >> GC runtime you're using. This contract is specific to the current ocaml >> code generator. > > Ocaml is compiled statically; this isn't an ephemeral link from JIT to > runtime as might be the case for a Java or Perl program.

On Aug 14, 2007, at 00:23, Chris Lattner wrote: > On Mon, 13 Aug 2007, Gordon Henriksen wrote: > >> Changing these structures breaks binary compatibility (including C >> interop). > > If that is so, and if there is no way around this, then it makes > sense to develop some compatibility mode. How does native C code > generate these tables? I might've

Jon, On 2007-11-24, at 21:58, Jon Harrop wrote: > I just took another look at the LLVM project and it has come along > in leaps and bounds since I last looked. I've been working through > the (awesome!) tutorial and am now really hyped about the project. Excellent! > I am particularly interested in using LLVM to write compilers for > OCaml-like languages in OCaml-like

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

On Nov 25, 2007, at 11:49, Jon Harrop wrote: > On Sunday 25 November 2007 12:23, Gordon Henriksen wrote: > >> On 2007-11-24, at 21:58, Jon Harrop wrote: >> >>> - Exceptions >> >> http://llvm.org/docs/ExceptionHandling.html >> >> LLVM's exception support is tuned toward DWARF "zero-cost >> exceptions," i.e. C++ exception

Hi, where can I read more about this? I assume (hope) the lib provides some kind of OCaml bindings? I could not find any trace of it in the 2.1 release source so I guess it's currently SVN only? greetings, Jan On 2. Okt 2007, at 12:22, Gordon Henriksen wrote: > On 2007-10-02, at 03:19, Gordon Henriksen wrote: > >> On Oct 2, 2007, at 00:17, Bill Wendling wrote: >>

Hello Yiannis, I believe what is going on is that there is an issue with the way that information is deleted (the CG information). Right now there is a pass whose only job is to delete that information (CGInfoDeleter) and that pass deletes the info before the AsmPrinter has a chance to call the finishAssembly function. Right now the order that the doFinalization is called on passes is the reverse

Hi, thanks Chris and Gordon for the fantasic infrastructure and ocaml bindings and Erick for the prompt response! I'm looking to use LLVM to write program analyses for C/C++ programs, but to use Ocaml to write the analyses. I did see there were bindings for iterating over: * functions in a module [iter_functions] * basic blocks in a functions [iter_blocks] * instructions in a block

> I just took another look at the LLVM project and it has come along in > leaps > and bounds since I last looked. I've been working through the (awesome!) > tutorial and am now really hyped about the project. > > I am particularly interested in using LLVM to write compilers for > OCaml-like > languages in OCaml-like languages. This requires some core functionality

On 2007-08-13, at 16:33, Chris Lattner wrote: >> The biggest problem is a data structure called the frame table, a >> simple structure for which LLVM seems ill-prepared. For each call >> site in the program, ocaml emits an entry into this table: >> >> key : the return address of the call site >> value : the stack offset of every variable live

Hi Jon, On 2007-12-10, at 18:28, Jon Harrop wrote: > On Monday 10 December 2007 23:14, Gordon Henriksen wrote: > >> On 2007-12-10, at 18:04, Sarah Thompson wrote: >> >>>> Is it reasonable for me to hack on this, or would you rather do >>>> it yourself? (If the latter, you would be very much in my debt...) >>> >>> Or the other way