From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBA0KN6a000410 for ; Sat, 10 Dec 2011 01:20:23 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkBABel4k7RVaG2imdsb2JhbABDhQaVRZAoCCIBAQEKCQ0HEgYhgXIBAQEBAxICDwQZAS0LAQMMAQUDAgsHBgICCR0CAiISAQUBCgQOBgoJEhCHbZkFCoscgzOEQIkuAgUMgSiCRIZkgRYEiDCMQI1xPYFNgko X-IronPort-AV: E=Sophos;i="4.71,329,1320620400"; d="scan'208";a="122809500" Received: from mail-gx0-f182.google.com ([209.85.161.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Dec 2011 01:20:17 +0100 Received: by ggnp1 with SMTP id p1so6307259ggn.27 for ; Fri, 09 Dec 2011 16:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vvI0rVlCyXYSRKTAvw+ZosZdEWb4cQ/rj6Xouq2SOgM=; b=bZdGmxa1RDjBWUm/+KghHweh5lAi8LDIGhURWyaWeLCRuJmRxdTnviKhb/OsnKUcTq OKLKGroEr53mjIVXEnMLY/PRhNAZHMwHJr2AW6qwnCNk3SG9cf+mcYilg2cjZi4SVsgk 87DMDTQYp2Gu+29Y0gnDkvZVkoC9S9ODuhb7M= MIME-Version: 1.0 Received: by 10.182.50.65 with SMTP id a1mr969537obo.17.1323476416457; Fri, 09 Dec 2011 16:20:16 -0800 (PST) Sender: till.varoquaux@gmail.com Received: by 10.182.216.99 with HTTP; Fri, 9 Dec 2011 16:20:16 -0800 (PST) In-Reply-To: <87aa712v26.fsf@frosties.localnet> References: <20111209065758.94306.qmail@eeoth.pair.com> <87aa712v26.fsf@frosties.localnet> Date: Fri, 9 Dec 2011 19:20:16 -0500 X-Google-Sender-Auth: k-7eRycnv2QDrhib8FOU1Rypses Message-ID: From: Till Varoquaux To: Goswin von Brederlow Cc: oleg@okmij.org, caml-list@inria.fr, ontologiae@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pBA0KN6a000410 X-Validation-by: till@pps.jussieu.fr Subject: Re: [Caml-list] Why NOT to compile OCaml via C You can use the bytecode compiler and interpreter on those architectures. If you feel adventurous you can compile ocaml to java or javascript and run wherever those languages run. The hypothetical ocaml->c compiler would have to interact with the garbage collector or use a different garbage collector; to be useful it would also need to present a compatible FFI to pre-existing stubs. You might also want to respect the limitations imposed by the current framework (exceptions for stack-overflows; 31/63 bits ints...). Writing portable C that low level is hard; generating it would be a lot of work. I very much doubt that anyone who understands what's at stake enough to be able to take a stab at it would consider this a productive use of their time. Till On Fri, Dec 9, 2011 at 6:18 PM, Goswin von Brederlow wrote: > oleg@okmij.org writes: > >> Pierre-Alexandre Voye wrote: >> >>> Note that if Ocaml compiler would have a C backend, all these problems or >>> architecture port would disappear... >>> Ocaml would have more than 30 target[1] >>> In my Opinion, trying to generate assembler is a bad idea because modern CPU >>> require a lot of work to generate good assembler. >> >> There are many good reasons to avoid C when compiling functional >> languages, especially strict ones. >> >> One often hears that ``C is a portable assembler''. That has never >> been true. One of the reasons is that every assembler I know has the >> "jmp" instruction, which, without affecting SP, transfers control >> anywhere, out of a procedure or in the middle of a procedure, out of a >> module or into a module. C is built around the stack discipline -- >> after all, C is a descendant of Algol 60. (Although C has labels, they >> are limited, even in GCC). Although Algol-60 researchers quickly >> recognized the value of tail recursion, all that knowledge was lost in >> the Dark Ages. > > Well, write the code as ONE function and do use lables. Sure, the C > source will be huge for larger projects but then again you get the > single source optimization bonus from gcc. > > Note: gcc does know something about tail recusion. So it is not > completly lost there. > > Personly I would like to have a ocaml -> C compiler. Not to replace the > one we have but for fun or as alternative on architectures that don't > have a native compiler (yet). It doesn't have to be hype efficient. If > it is somwhere between the bytecode and native speed that would be > totally fine. > > MfG >        Goswin > > -- > Caml-list mailing list.  Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >