From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 8F3EB7EE25 for ; Fri, 8 Nov 2013 12:44:37 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of whitequark@whitequark.org) identity=pra; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of whitequark@whitequark.org designates 176.58.103.125 as permitted sender) identity=mailfrom; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="whitequark@whitequark.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.whitequark.org) identity=helo; client-ip=176.58.103.125; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="whitequark@whitequark.org"; x-sender="postmaster@mail.whitequark.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsMAE7OfFKwOmd9/2dsb2JhbABahjJUhkeyLoMqgUJ0giUBAQQBIw8BBUEMBAQFAhEEAQEDAiMDAgIsGgkIBhMIh3MKjmibXpJMgSmIEYYtBwYQglWBRQOJPKBegys3 X-IPAS-Result: ArsMAE7OfFKwOmd9/2dsb2JhbABahjJUhkeyLoMqgUJ0giUBAQQBIw8BBUEMBAQFAhEEAQEDAiMDAgIsGgkIBhMIh3MKjmibXpJMgSmIEYYtBwYQglWBRQOJPKBegys3 X-IronPort-AV: E=Sophos;i="4.93,659,1378850400"; d="scan'208";a="34431766" Received: from fehu.whitequark.org (HELO mail.whitequark.org) ([176.58.103.125]) by mail3-smtp-sop.national.inria.fr with ESMTP; 08 Nov 2013 12:44:36 +0100 Received: by mail.whitequark.org (Postfix, from userid 33) id 74BFF4D715; Fri, 8 Nov 2013 15:44:35 +0400 (MSK) To: X-PHP-Originating-Script: 1000:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 08 Nov 2013 15:44:35 +0400 From: Peter Zotov Cc: In-Reply-To: <012101cedc76$1665b920$43312b60$@ffconsultancy.com> References: <010801cedc66$0425bcc0$0c713640$@ffconsultancy.com> <14f25a35d63f2b6ce6185d86dc66d2bd@whitequark.org> <012101cedc76$1665b920$43312b60$@ffconsultancy.com> Message-ID: X-Sender: whitequark@whitequark.org User-Agent: Roundcube Webmail/0.8.6 Subject: RE: [Caml-list] LLVM OCaml bindings Jon Harrop писал 08.11.2013 15:31: >> I'm not going to change APIs in any way which needs nontrivial, >> significant fixes to clients, there's simply no need. > > Ok, great. > > Jeff Meister was talking about writing more type safe bindings. I > think that would be fine as long as it wraps the existing less-safe > bindings so people can continue to use them. I tried using LLVM from > Haskell and had a lot of problems because they'd used every trick in > the book to write the most type safe possible bindings and it makes it > much harder to learn and use. I'd personally much rather see more > complete bindings... I completely agree. I don't currently know if I will write type-safe bindings (if I do, they'll be based on OCaml's OO... it's a nearly perfect match for the kind of API LLVM has), but they'll be based on the low-level bindings, not replace them. By the way, I'm currently in process of upstreaming all extensions for the C API the Haskell (llvm-general) bindings internally have. > > BTW, what are your thoughts on MSJIT? I just started reading about it > and it seems very underwhelming. Sounds like they're struggling to > refactor their C++ code so they're reinventing things but not doing it > significantly better. So I don't think I'll be rushing to switch to > MSJIT unless they actually deprecate the old JIT. MCJIT is a great idea in general, since it reuses much more of the LLVM infrastructure, in particular the MC layer, so you don't have two different code generators to maintain. Right now it's very incomplete and I won't use it yet. There seems to be a moderate interest in a better MCJIT so I hope it becomes much more usable in the next few months. As I understand it, the old JIT is already deprecated, it's just not removed yet (and will not be for a while). > > Cheers, > Jon. > > -----Original Message----- > From: Peter Zotov [mailto:whitequark@whitequark.org] > Sent: 08 November 2013 10:19 > To: jon@ffconsultancy.com > Cc: caml-list@inria.fr > Subject: RE: [Caml-list] LLVM OCaml bindings > > Jon Harrop писал 08.11.2013 13:36: >> I just wanted to check: you're not breaking the existing bindings, >> right? > > Sorry, realized the previous letter was phrased ambiguously. > I'm asking because I do want to break existing bindings. The changes > would mainly touch two areas: > 1) Memory management. I want to get rid of most or all of dispose > functions and allow to use OCaml's GC. > 2) Llvm_target interface is very outdated and it could be updated to > integrate much better with the TargetMachine interface. > > There are also two or three Llvm functions which need minor changes. > > I'm not going to change APIs in any way which needs nontrivial, > significant fixes to clients, there's simply no need. > > -- > WBR, Peter Zotov. -- WBR, Peter Zotov.