* Compiling Ocaml sources to c sources @ 2010-09-14 12:09 Vincent Gripon 2010-09-14 12:16 ` [Caml-list] Compiling Ocaml sources to c sources [NC] Rabih CHAAR ` (3 more replies) 0 siblings, 4 replies; 19+ messages in thread From: Vincent Gripon @ 2010-09-14 12:09 UTC (permalink / raw) To: caml-list [-- Attachment #1.1: Type: text/plain, Size: 719 bytes --] Hello, We are currently planing to participate to a programming contest. This contest allows the use of four languages (C/C#/C++/java) but not OCaml. We would like to use Ocaml as it is to us the language that fits the most the kind of exercises proposed. The organizers don't mind if we use OCaml as long as we provide an easily compilable C source to them, even if it is not readable. Is there any platform independent way to compile OCaml sources to C sources? And if not, do you have any pointer (we gave a try at compiling OCaml sources to C object files using the -output-obj option but couldn't compile then the resulting file with our C compiler)? Best, Vincent <mailto:caml-list@yquem.inria.fr> [-- Attachment #1.2: Type: text/html, Size: 1531 bytes --] [-- Attachment #2: vincent_gripon.vcf --] [-- Type: text/x-vcard, Size: 354 bytes --] begin:vcard fn:Vincent Gripon n:Gripon;Vincent org:Telecom Bretagne;Computer Science and Telecommunications adr:;;Telecom Bretagne - Technopole Brest Iroise;Brest Cedex 3;;29238;France email;internet:vincent.gripon@ens-cachan.org title:PhD Student tel;work:+0033 2 29 00 1586 url:http://perso.eleves.bretagne.ens-cachan.fr/~gripon version:2.1 end:vcard ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources [NC] 2010-09-14 12:09 Compiling Ocaml sources to c sources Vincent Gripon @ 2010-09-14 12:16 ` Rabih CHAAR 2010-09-14 12:35 ` [Caml-list] Compiling Ocaml sources to c sources David MENTRE ` (2 subsequent siblings) 3 siblings, 0 replies; 19+ messages in thread From: Rabih CHAAR @ 2010-09-14 12:16 UTC (permalink / raw) To: Vincent Gripon; +Cc: caml-list, caml-list-bounces [-- Attachment #1: Type: text/plain, Size: 2745 bytes --] Hello, when compiling ocaml to bytecode with the -output-obj flag, a c file is created containing essentially the produced bytecode in a c array, which will be fed to caml via caml-startup functions. This doesn't relate to generating C source with a translation for your functional code in Ocaml. I don't have any knowledge of a tool that covers your need, but i am not an expert on these issues. Sincerely, Rabih Chaar Vincent Gripon <vincent.gripon@telecom-bretagne.eu> Sent by: caml-list-bounces@yquem.inria.fr 14/09/10 02:09 PM To caml-list@yquem.inria.fr cc Subject [Caml-list] Compiling Ocaml sources to c sources Hello, We are currently planing to participate to a programming contest. This contest allows the use of four languages (C/C#/C++/java) but not OCaml. We would like to use Ocaml as it is to us the language that fits the most the kind of exercises proposed. The organizers don't mind if we use OCaml as long as we provide an easily compilable C source to them, even if it is not readable. Is there any platform independent way to compile OCaml sources to C sources? And if not, do you have any pointer (we gave a try at compiling OCaml sources to C object files using the -output-obj option but couldn't compile then the resulting file with our C compiler)? Best, Vincent[attachment "vincent_gripon.vcf" deleted by Rabih CHAAR/fr/socgen] _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ************************************************************************* This message and any attachments (the "message") are confidential, intended solely for the addressee(s), and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************ Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. ************************************************************************* [-- Attachment #2: Type: text/html, Size: 3879 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-14 12:09 Compiling Ocaml sources to c sources Vincent Gripon 2010-09-14 12:16 ` [Caml-list] Compiling Ocaml sources to c sources [NC] Rabih CHAAR @ 2010-09-14 12:35 ` David MENTRE 2010-09-15 13:18 ` Vincent Gripon 2010-09-14 12:43 ` Basile Starynkevitch 2010-09-14 12:47 ` Thomas Gazagnaire 3 siblings, 1 reply; 19+ messages in thread From: David MENTRE @ 2010-09-14 12:35 UTC (permalink / raw) To: Vincent Gripon; +Cc: caml-list Hello, 2010/9/14 Vincent Gripon <vincent.gripon@telecom-bretagne.eu>: > Is there any platform independent way to compile OCaml sources to C sources? Probably stupid answer: compile to byte code and provide the source code of the C OCaml byte code interpreter with the program embedded as C structure? Sincerely yours, david ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-14 12:35 ` [Caml-list] Compiling Ocaml sources to c sources David MENTRE @ 2010-09-15 13:18 ` Vincent Gripon 2010-09-15 19:59 ` Basile Starynkevitch 0 siblings, 1 reply; 19+ messages in thread From: Vincent Gripon @ 2010-09-15 13:18 UTC (permalink / raw) To: David MENTRE; +Cc: caml-list [-- Attachment #1: Type: text/plain, Size: 627 bytes --] Hello David, This is a good idea. Basile made a just in time implementation which is preferable to us as we do not know if the contest has time constraints on the compilation of submitted sources. Thank you for your answer. Cheers. On 09/14/2010 02:35 PM, David MENTRE wrote: > Hello, > > 2010/9/14 Vincent Gripon<vincent.gripon@telecom-bretagne.eu>: >> Is there any platform independent way to compile OCaml sources to C sources? > Probably stupid answer: compile to byte code and provide the source > code of the C OCaml byte code interpreter with the program embedded as > C structure? > > Sincerely yours, > david > [-- Attachment #2: vincent_gripon.vcf --] [-- Type: text/x-vcard, Size: 354 bytes --] begin:vcard fn:Vincent Gripon n:Gripon;Vincent org:Telecom Bretagne;Computer Science and Telecommunications adr:;;Telecom Bretagne - Technopole Brest Iroise;Brest Cedex 3;;29238;France email;internet:vincent.gripon@ens-cachan.org title:PhD Student tel;work:+0033 2 29 00 1586 url:http://perso.eleves.bretagne.ens-cachan.fr/~gripon version:2.1 end:vcard ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-15 13:18 ` Vincent Gripon @ 2010-09-15 19:59 ` Basile Starynkevitch 2010-09-15 22:16 ` Vincent Gripon 0 siblings, 1 reply; 19+ messages in thread From: Basile Starynkevitch @ 2010-09-15 19:59 UTC (permalink / raw) To: Vincent Gripon; +Cc: David MENTRE, caml-list On Wed, 15 Sep 2010 15:18:39 +0200 Vincent Gripon <vincent.gripon@telecom-bretagne.eu> wrote: > Hello David, > > This is a good idea. Basile made a just in time implementation which is > preferable to us as we do not know if the contest has time constraints > on the compilation of submitted sources. But my ocamljitrun.c still needs your ocaml sources to be compiled by ocamlc. And you could use ocaml instead. And ocamlopt compiles source code quite quickly in practice (faster that gcc is handling source code compiled with -O2). Did you ask the contest organizer if ocaml is a valid language? Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-15 19:59 ` Basile Starynkevitch @ 2010-09-15 22:16 ` Vincent Gripon 0 siblings, 0 replies; 19+ messages in thread From: Vincent Gripon @ 2010-09-15 22:16 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: David MENTRE, caml-list [-- Attachment #1: Type: text/plain, Size: 1180 bytes --] > But my ocamljitrun.c still needs your ocaml sources to be compiled by > ocamlc. And you could use ocaml instead. It appears to us simpler (but maybe it is not?) to compile and provide the ocamljit implementation than the ocaml classical interpreter. > And ocamlopt compiles source code quite quickly in practice (faster > that gcc is handling source code compiled with -O2). I was more concerned about the time to compile the compiler than the time for it to compile our sources. > Did you ask the contest organizer if ocaml is a valid language? It is hard to find this information on the website but only four languages are allowed: C/C++/C# and java. We emailed the organizers explaining that functional languages should also be proposed in the contest, and asked them whether it would be accepted to provide them with a C source code likely hard to read but compiling with minimal prerequisites and executing our program. As long as we accept to provide them with the original source code if they ask it, they find no objection to it. Hopefully if we manage to reach a high rank they will consider adding OCaml for next year contest ;) Cheers, Vincent. [-- Attachment #2: vincent_gripon.vcf --] [-- Type: text/x-vcard, Size: 354 bytes --] begin:vcard fn:Vincent Gripon n:Gripon;Vincent org:Telecom Bretagne;Computer Science and Telecommunications adr:;;Telecom Bretagne - Technopole Brest Iroise;Brest Cedex 3;;29238;France email;internet:vincent.gripon@ens-cachan.org title:PhD Student tel;work:+0033 2 29 00 1586 url:http://perso.eleves.bretagne.ens-cachan.fr/~gripon version:2.1 end:vcard ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-14 12:09 Compiling Ocaml sources to c sources Vincent Gripon 2010-09-14 12:16 ` [Caml-list] Compiling Ocaml sources to c sources [NC] Rabih CHAAR 2010-09-14 12:35 ` [Caml-list] Compiling Ocaml sources to c sources David MENTRE @ 2010-09-14 12:43 ` Basile Starynkevitch 2010-09-15 12:59 ` Vincent Gripon 2010-09-15 17:36 ` Jon Harrop 2010-09-14 12:47 ` Thomas Gazagnaire 3 siblings, 2 replies; 19+ messages in thread From: Basile Starynkevitch @ 2010-09-14 12:43 UTC (permalink / raw) To: Vincent Gripon, caml-list On Tue, Sep 14, 2010 at 02:09:47PM +0200, Vincent Gripon wrote: > Hello, > > We are currently planing to participate to a programming contest. It would be interesting for us to know more about that contest. > This contest allows the use of four languages (C/C#/C++/java) but > not OCaml. That does not mean much. What about libraries you are calling from C? In particular: * can you use any library? This seems strange (because the organizers very probably won't have the same libraries or versions as you have). * do you have any restrictions on the libraries you are using? * at the extreme case, the competition might require you to provide all the sources of every non standard (in the sense of ISO C standard) libraries you are using, and a verified mean to build them. What about POSIX system calls? > > We would like to use Ocaml as it is to us the language that fits the > most the kind of exercises proposed. The organizers don't mind if we > use OCaml as long as we provide an easily compilable C source to > them, even if it is not readable. > > Is there any platform independent way to compile OCaml sources to C > sources? I don't see any easy way to do that. There are several issues * the Ocaml runtime environment, which not only includes its garbage collector but also all the ocaml runtime library. * Hacking a C generator inside Ocaml is non-trivial, because of the garbage collector, currified function calls, and tail recursion etc. * If you really insist on coding in Ocaml and if you don't care much about performance, you could take my bit-rotten Ocamljit work (I forgot where you can find it, and I don't have it anymore, but google should help finding it) and make something which transform the entire bytecode of an Ocaml program into a gigantic single C function (translating straightforwardly every byte code into a small chunk of C code). This is not easy to do, and it might not be fun neither. Very probably, a C compiler would have pain to optimize such a big function (by personal experience, the GCC compiler usually take O(n^2) time to optimize with -O2 a sufficiently large function of size n, and may also need O(n^2) memory). And such an approach might not produce portable code (perhaps there are some issues w.r.t. 32 vs 64 bits systems). Actually, portable C is a fiction: only ported C programs can exist. Did you also consider using Scheme, it has several implementations generating C code (Chicken & Stalin come to mind). But still, programming in C does not mean much! What about portability? building? external libraries? linking other stuff? target system? If you have complete freedom on what you link with your program, you could hack a libocamlrun to be linkable, and link the bytecode as an array, as suggested previously. I would imagine that preparing stuff to make you code in Ocaml and fit into the contest rules is a big lot of work. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-14 12:43 ` Basile Starynkevitch @ 2010-09-15 12:59 ` Vincent Gripon 2010-09-15 17:36 ` Jon Harrop 1 sibling, 0 replies; 19+ messages in thread From: Vincent Gripon @ 2010-09-15 12:59 UTC (permalink / raw) To: Basile Starynkevitch; +Cc: caml-list [-- Attachment #1: Type: text/plain, Size: 3924 bytes --] Thanks for your answer, On 09/14/2010 02:43 PM, Basile Starynkevitch wrote: > On Tue, Sep 14, 2010 at 02:09:47PM +0200, Vincent Gripon wrote: >> Hello, >> >> We are currently planing to participate to a programming contest. > It would be interesting for us to know more about that contest. We are entering the IEEEXtreme programming competition ( http://www.ieee.org/membership_services/membership/students/competitions/xtreme/index.html ). >> This contest allows the use of four languages (C/C#/C++/java) but >> not OCaml. > That does not mean much. What about libraries you are calling from C? > > In particular: > > * can you use any library? This seems strange (because the > organizers very probably won't have the same libraries or versions > as you have). > > * do you have any restrictions on the libraries you are using? > > * at the extreme case, the competition might require you to provide > all the sources of every non standard (in the sense of ISO C > standard) libraries you are using, and a verified mean to build > them. What about POSIX system calls? There is very little information on these aspects, it looks like only the basic gcc compilers are available. The proposed exercises will probably not require any library or complicated system call, as it is more an algorithmic contest than system one. > >> We would like to use Ocaml as it is to us the language that fits the >> most the kind of exercises proposed. The organizers don't mind if we >> use OCaml as long as we provide an easily compilable C source to >> them, even if it is not readable. >> >> Is there any platform independent way to compile OCaml sources to C >> sources? > I don't see any easy way to do that. There are several issues > > * the Ocaml runtime environment, which not only includes its garbage > collector but also all the ocaml runtime library. > > * Hacking a C generator inside Ocaml is non-trivial, because of the > garbage collector, currified function calls, and tail recursion > etc. > > * If you really insist on coding in Ocaml and if you don't care much > about performance, you could take my bit-rotten Ocamljit work (I > forgot where you can find it, and I don't have it anymore, but > google should help finding it) and make something which transform > the entire bytecode of an Ocaml program into a gigantic single C > function (translating straightforwardly every byte code into a > small chunk of C code). This is not easy to do, and it might not > be fun neither. Very probably, a C compiler would have pain to > optimize such a big function (by personal experience, the GCC > compiler usually take O(n^2) time to optimize with -O2 a > sufficiently large function of size n, and may also need O(n^2) > memory). And such an approach might not produce portable code > (perhaps there are some issues w.r.t. 32 vs 64 bits > systems). Actually, portable C is a fiction: only ported C > programs can exist. We downloaded your software and it works perfectly well (with ocaml 3.09). It seems perfectly suited for the contest rules and we are planing to use it in this regard if it does not bother you. > > Did you also consider using Scheme, it has several implementations > generating C code (Chicken & Stalin come to mind). > > But still, programming in C does not mean much! What about > portability? building? external libraries? linking other stuff? target > system? > > If you have complete freedom on what you link with your program, you > could hack a libocamlrun to be linkable, and link the bytecode as an > array, as suggested previously. > > I would imagine that preparing stuff to make you code in Ocaml and fit > into the contest rules is a big lot of work. Thanks to your software, it should not be =) Cheers. [-- Attachment #2: vincent_gripon.vcf --] [-- Type: text/x-vcard, Size: 354 bytes --] begin:vcard fn:Vincent Gripon n:Gripon;Vincent org:Telecom Bretagne;Computer Science and Telecommunications adr:;;Telecom Bretagne - Technopole Brest Iroise;Brest Cedex 3;;29238;France email;internet:vincent.gripon@ens-cachan.org title:PhD Student tel;work:+0033 2 29 00 1586 url:http://perso.eleves.bretagne.ens-cachan.fr/~gripon version:2.1 end:vcard ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [Caml-list] Compiling Ocaml sources to c sources 2010-09-14 12:43 ` Basile Starynkevitch 2010-09-15 12:59 ` Vincent Gripon @ 2010-09-15 17:36 ` Jon Harrop 2010-09-15 18:17 ` Eray Ozkural 1 sibling, 1 reply; 19+ messages in thread From: Jon Harrop @ 2010-09-15 17:36 UTC (permalink / raw) To: 'Basile Starynkevitch', 'Vincent Gripon', caml-list > * Hacking a C generator inside Ocaml is non-trivial, because of the > garbage collector, currified function calls, and tail recursion > etc. BTW, I was always surprised nobody had converted the bytecode interpreter into a via-C compiler by unwinding the C code the interpreter goes through to execute a specific OCaml bytecode program. You could even use this with something like Clang to get JIT compilation to native code. Not very efficient but surely much faster than interpreted bytecode... Cheers, Jon. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-15 17:36 ` Jon Harrop @ 2010-09-15 18:17 ` Eray Ozkural 2010-09-15 20:37 ` Jon Harrop 0 siblings, 1 reply; 19+ messages in thread From: Eray Ozkural @ 2010-09-15 18:17 UTC (permalink / raw) To: Jon Harrop; +Cc: Basile Starynkevitch, Vincent Gripon, caml-list [-- Attachment #1: Type: text/plain, Size: 1234 bytes --] On Wed, Sep 15, 2010 at 8:36 PM, Jon Harrop < jonathandeanharrop@googlemail.com> wrote: > > * Hacking a C generator inside Ocaml is non-trivial, because of the > > garbage collector, currified function calls, and tail recursion > > etc. > > BTW, I was always surprised nobody had converted the bytecode interpreter > into a via-C compiler by unwinding the C code the interpreter goes through > to execute a specific OCaml bytecode program. You could even use this with > something like Clang to get JIT compilation to native code. Not very > efficient but surely much faster than interpreted bytecode... > Hmm, this would only optimize the bytecode fetch/decode step of the ocaml execution cycle. I am not sure that it will result in much real-world speedup. In fact, that seems to be the main problem with many of these so-called JIT interpreters, which in my opinion, do not seem to have learnt from the HAL architectures of IBM OS's etc. Was probably also the problem with Transmeta; cheap compilation entails cheap performance. Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct [-- Attachment #2: Type: text/html, Size: 1781 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [Caml-list] Compiling Ocaml sources to c sources 2010-09-15 18:17 ` Eray Ozkural @ 2010-09-15 20:37 ` Jon Harrop 2010-09-16 0:38 ` Eray Ozkural 0 siblings, 1 reply; 19+ messages in thread From: Jon Harrop @ 2010-09-15 20:37 UTC (permalink / raw) To: 'Eray Ozkural', 'Jon Harrop' Cc: 'Basile Starynkevitch', 'Vincent Gripon', caml-list > Hmm, this would only optimize the bytecode fetch/decode step of the ocaml execution cycle. I am not sure that it will result in much real-world speedup. Would be interesting to try. I suspect the C compiler would then optimize the sequences of operations on the data as well. For example, something like vector addition. > In fact, that seems to be the main problem with many of these so-called JIT interpreters, which in my opinion, do not seem to have learnt from the HAL architectures of IBM OS's etc. Was probably also the problem with Transmeta; cheap compilation entails cheap performance. Can you elaborate? Cheers, Jon. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-15 20:37 ` Jon Harrop @ 2010-09-16 0:38 ` Eray Ozkural 2010-09-16 9:05 ` Fabrice Le Fessant 0 siblings, 1 reply; 19+ messages in thread From: Eray Ozkural @ 2010-09-16 0:38 UTC (permalink / raw) To: Jon Harrop; +Cc: Basile Starynkevitch, Vincent Gripon, caml-list [-- Attachment #1: Type: text/plain, Size: 1985 bytes --] On Wed, Sep 15, 2010 at 11:37 PM, Jon Harrop < jonathandeanharrop@googlemail.com> wrote: > > Hmm, this would only optimize the bytecode fetch/decode step of the ocaml > execution cycle. I am not sure that it will result in much real-world > speedup. > > Would be interesting to try. I suspect the C compiler would then optimize > the sequences of operations on the data as well. For example, something > like > vector addition. > > > In fact, that seems to be the main problem with many of these so-called > JIT interpreters, which in my opinion, do not seem to have learnt from the > HAL architectures of IBM OS's etc. Was probably also the problem with > Transmeta; cheap compilation entails cheap performance. > > Can you elaborate? > > Well, what I would do is to apply a fully optimizing compiler from a proper hardware abstraction layer, whether it is JIT is irrelevant, but I do not see why the system would not start doing this as soon as the code is loaded in some place (and not when it starts to run). What is certain is that some simple transformation will not speed things up much. The right way to do it is to determine hot blocks beforehand. Hot blocks can also be determined on the fly but I do not think that JIT is much needed. The time of the determination of hot blocks is most certainly not crucial to optimizations, although the more time compiler has, the better. Simple optimizations will not have much impact. It is not like you can undo the complexity of an optimizing compiler just because you have JIT. In Transmeta's case, you can't translate an obsolete RISC code to efficient VLIW in real-time. This seems to be putting too much strain on the translation. Which ought to be obvious given the complexity of VLIW compilers? Sometimes outsiders have a better view. Best, -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct [-- Attachment #2: Type: text/html, Size: 2600 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-16 0:38 ` Eray Ozkural @ 2010-09-16 9:05 ` Fabrice Le Fessant 2010-09-16 10:46 ` Eray Ozkural 0 siblings, 1 reply; 19+ messages in thread From: Fabrice Le Fessant @ 2010-09-16 9:05 UTC (permalink / raw) To: caml-list The problem is still the same: even if the code is compiled by a C compiler, there is still the need for the garbage collector. If you don't provide your own conservative GC (for which you would have to reimplement all the native functions of OCaml), then you need to use OCaml GC, and you would have to disable most optimizations to be sure that the GC knows where to find live references. At the end, you would get almost no performance improvement, compared to just appending the assembly code for each bytecode instruction (see Piumarta's work in PLDI'98). --Fabrice Eray Ozkural wrote, On 09/16/2010 02:38 AM: > Well, what I would do is to apply a fully optimizing compiler from a > proper hardware abstraction layer, whether it is JIT is irrelevant, but > I do not see why the system would not start doing this as soon as the > code is loaded in some place (and not when it starts to run). What is > certain is that some simple transformation will not speed things up much. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-16 9:05 ` Fabrice Le Fessant @ 2010-09-16 10:46 ` Eray Ozkural 2010-09-16 11:11 ` Fabrice Le Fessant 0 siblings, 1 reply; 19+ messages in thread From: Eray Ozkural @ 2010-09-16 10:46 UTC (permalink / raw) To: Fabrice Le Fessant; +Cc: caml-list [-- Attachment #1: Type: text/plain, Size: 2070 bytes --] Yes, I've seen how wired the GC is in the ocaml sources. I had used the Boehm GC in a compiler project (not for the generated code but the compiler), do you mean that one would have to disable most optimizations in the ocaml bytecode compiler to make such a hypothetical bytecode-to-C compiler work with a C GC, or am I missing something crucial? It's great to be able to learn from actual ocaml compiler writers, BTW, your comments are much appreciated. Regards, On Thu, Sep 16, 2010 at 12:05 PM, Fabrice Le Fessant < fabrice.le_fessant@inria.fr> wrote: > The problem is still the same: even if the code is compiled by a C > compiler, there is still the need for the garbage collector. If you > don't provide your own conservative GC (for which you would have to > reimplement all the native functions of OCaml), then you need to use > OCaml GC, and you would have to disable most optimizations to be sure > that the GC knows where to find live references. At the end, you would > get almost no performance improvement, compared to just appending the > assembly code for each bytecode instruction (see Piumarta's work in > PLDI'98). > > --Fabrice > > Eray Ozkural wrote, On 09/16/2010 02:38 AM: > > Well, what I would do is to apply a fully optimizing compiler from a > > proper hardware abstraction layer, whether it is JIT is irrelevant, but > > I do not see why the system would not start doing this as soon as the > > code is loaded in some place (and not when it starts to run). What is > > certain is that some simple transformation will not speed things up much. > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara http://groups.yahoo.com/group/ai-philosophy http://myspace.com/arizanesil http://myspace.com/malfunct [-- Attachment #2: Type: text/html, Size: 3048 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-16 10:46 ` Eray Ozkural @ 2010-09-16 11:11 ` Fabrice Le Fessant 0 siblings, 0 replies; 19+ messages in thread From: Fabrice Le Fessant @ 2010-09-16 11:11 UTC (permalink / raw) To: Eray Ozkural; +Cc: caml-list You could use Boehm's garbage-collector for such a project, indeed, that's what is done in Bigloo, to compile Scheme programs to C. Since Boehm's GC is conservative, it would probably work well in such a system, with or without compiler optimizations, but the GC itself would probably be much slower than OCaml's GC on monothreaded code. On the contrary, OCaml's GC is not conservative, so it really needs to know what is a pointer to OCaml data, and also to be warned when pointers to OCaml data are erased (what caml_modify does). If you leave the C compiler perform all its optimizations, you might end up with pointers to OCaml data that are not where they should be (typically, it can duplicate a variable to parallelize some computations when there are no dependencies between them, and the GC will only scan one of them). So, you have to limit the C compiler to only "safe" optimizations from that point of view. By the way, there are almost no optimizations performed in the Ocaml compiler on bytecode, most of the interesting ones are only performed in the native compiler. I think the philosophy behind this choice is that you want to compile very fast to bytecode (so, no time for optimization), and only use the native code compiler at the end for efficient code. --Fabrice On Thu, Sep 16, 2010 at 12:46 PM, Eray Ozkural <examachine@gmail.com> wrote: > Yes, I've seen how wired the GC is in the ocaml sources. I had used the > Boehm GC in a compiler project (not for the generated code but the > compiler), > do you mean that one would have to disable most optimizations in the ocaml > bytecode > compiler to make such a hypothetical bytecode-to-C compiler work with a C > GC, or am I missing something crucial? It's great to be able to learn from > actual > ocaml compiler writers, BTW, your comments are much appreciated. > Regards, > On Thu, Sep 16, 2010 at 12:05 PM, Fabrice Le Fessant > <fabrice.le_fessant@inria.fr> wrote: >> >> The problem is still the same: even if the code is compiled by a C >> compiler, there is still the need for the garbage collector. If you >> don't provide your own conservative GC (for which you would have to >> reimplement all the native functions of OCaml), then you need to use >> OCaml GC, and you would have to disable most optimizations to be sure >> that the GC knows where to find live references. At the end, you would >> get almost no performance improvement, compared to just appending the >> assembly code for each bytecode instruction (see Piumarta's work in >> PLDI'98). >> >> --Fabrice >> >> Eray Ozkural wrote, On 09/16/2010 02:38 AM: >> > Well, what I would do is to apply a fully optimizing compiler from a >> > proper hardware abstraction layer, whether it is JIT is irrelevant, but >> > I do not see why the system would not start doing this as soon as the >> > code is loaded in some place (and not when it starts to run). What is >> > certain is that some simple transformation will not speed things up >> > much. >> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-14 12:09 Compiling Ocaml sources to c sources Vincent Gripon ` (2 preceding siblings ...) 2010-09-14 12:43 ` Basile Starynkevitch @ 2010-09-14 12:47 ` Thomas Gazagnaire 2010-09-14 12:48 ` Grant Rettke 2010-09-15 13:04 ` Vincent Gripon 3 siblings, 2 replies; 19+ messages in thread From: Thomas Gazagnaire @ 2010-09-14 12:47 UTC (permalink / raw) To: Vincent Gripon; +Cc: caml-list Hi Vincent! you can try camloo [1] which compiles (old-syntax) caml-light to bigloo, which is a scheme to C compiler. I reckon it would be quite easy to update it to parse the ocaml syntax if you don't use functors/objects/variants/labels/thread (ie. if you use only what is available in caml-light). Cheers, Thomas [1] http://www-sop.inria.fr/members/Thomas.Gazagnaire/ On Tue, 2010-09-14 at 14:09 +0200, Vincent Gripon wrote: > Hello, > > We are currently planing to participate to a programming contest. This > contest allows the use of four languages (C/C#/C++/java) but not > OCaml. > > We would like to use Ocaml as it is to us the language that fits the > most the kind of exercises proposed. The organizers don't mind if we > use OCaml as long as we provide an easily compilable C source to them, > even if it is not readable. > > Is there any platform independent way to compile OCaml sources to C > sources? And if not, do you have any pointer (we gave a try at > compiling OCaml sources to C object files using the -output-obj option > but couldn't compile then the resulting file with our C compiler)? > > Best, > > Vincent > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-14 12:47 ` Thomas Gazagnaire @ 2010-09-14 12:48 ` Grant Rettke 2010-09-15 13:04 ` Vincent Gripon 1 sibling, 0 replies; 19+ messages in thread From: Grant Rettke @ 2010-09-14 12:48 UTC (permalink / raw) To: Thomas Gazagnaire; +Cc: Vincent Gripon, caml-list OCaml compiled by F# called by C#? On Tue, Sep 14, 2010 at 7:47 AM, Thomas Gazagnaire <thomas.gazagnaire@inria.fr> wrote: > Hi Vincent! > > you can try camloo [1] which compiles (old-syntax) caml-light to bigloo, > which is a scheme to C compiler. I reckon it would be quite easy to > update it to parse the ocaml syntax if you don't use > functors/objects/variants/labels/thread (ie. if you use only what is > available in caml-light). > > Cheers, > Thomas > > [1] http://www-sop.inria.fr/members/Thomas.Gazagnaire/ > > > On Tue, 2010-09-14 at 14:09 +0200, Vincent Gripon wrote: >> Hello, >> >> We are currently planing to participate to a programming contest. This >> contest allows the use of four languages (C/C#/C++/java) but not >> OCaml. >> >> We would like to use Ocaml as it is to us the language that fits the >> most the kind of exercises proposed. The organizers don't mind if we >> use OCaml as long as we provide an easily compilable C source to them, >> even if it is not readable. >> >> Is there any platform independent way to compile OCaml sources to C >> sources? And if not, do you have any pointer (we gave a try at >> compiling OCaml sources to C object files using the -output-obj option >> but couldn't compile then the resulting file with our C compiler)? >> >> Best, >> >> Vincent >> _______________________________________________ >> Caml-list mailing list. Subscription management: >> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list >> Archives: http://caml.inria.fr >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs > > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- http://www.wisdomandwonder.com/ ACM, AMA, COG, IEEE ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-14 12:47 ` Thomas Gazagnaire 2010-09-14 12:48 ` Grant Rettke @ 2010-09-15 13:04 ` Vincent Gripon 2010-09-15 19:57 ` Basile Starynkevitch 1 sibling, 1 reply; 19+ messages in thread From: Vincent Gripon @ 2010-09-15 13:04 UTC (permalink / raw) To: Thomas Gazagnaire; +Cc: caml-list [-- Attachment #1: Type: text/plain, Size: 1732 bytes --] Hi Thomas, Basile's suggestion allows us to use the whole OCaml syntax with no real need for coding. That's why we are planing to use it. Thank you for your solution. Cheers! On 09/14/2010 02:47 PM, Thomas Gazagnaire wrote: > Hi Vincent! > > you can try camloo [1] which compiles (old-syntax) caml-light to bigloo, > which is a scheme to C compiler. I reckon it would be quite easy to > update it to parse the ocaml syntax if you don't use > functors/objects/variants/labels/thread (ie. if you use only what is > available in caml-light). > > Cheers, > Thomas > > [1] http://www-sop.inria.fr/members/Thomas.Gazagnaire/ > > > On Tue, 2010-09-14 at 14:09 +0200, Vincent Gripon wrote: >> Hello, >> >> We are currently planing to participate to a programming contest. This >> contest allows the use of four languages (C/C#/C++/java) but not >> OCaml. >> >> We would like to use Ocaml as it is to us the language that fits the >> most the kind of exercises proposed. The organizers don't mind if we >> use OCaml as long as we provide an easily compilable C source to them, >> even if it is not readable. >> >> Is there any platform independent way to compile OCaml sources to C >> sources? And if not, do you have any pointer (we gave a try at >> compiling OCaml sources to C object files using the -output-obj option >> but couldn't compile then the resulting file with our C compiler)? >> >> Best, >> >> Vincent >> _______________________________________________ >> Caml-list mailing list. Subscription management: >> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list >> Archives: http://caml.inria.fr >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs > [-- Attachment #2: vincent_gripon.vcf --] [-- Type: text/x-vcard, Size: 366 bytes --] begin:vcard fn:Vincent Gripon n:Gripon;Vincent org:Telecom Bretagne;Computer Science and Telecommunications adr:;;Telecom Bretagne - Technopole Brest Iroise;Brest Cedex 3;;29238;France email;internet:vincent.gripon@ens-cachan.org title:PhD Student tel;work:+0033 2 29 00 1586 url:http://perso.eleves.bretagne.ens-cachan.fr/~gripon version:2.1 end:vcard ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Caml-list] Compiling Ocaml sources to c sources 2010-09-15 13:04 ` Vincent Gripon @ 2010-09-15 19:57 ` Basile Starynkevitch 0 siblings, 0 replies; 19+ messages in thread From: Basile Starynkevitch @ 2010-09-15 19:57 UTC (permalink / raw) To: Vincent Gripon; +Cc: Thomas Gazagnaire, caml-list On Wed, 15 Sep 2010 15:04:30 +0200 Vincent Gripon <vincent.gripon@telecom-bretagne.eu> wrote: > Hi Thomas, > > Basile's suggestion allows us to use the whole OCaml syntax with no real > need for coding. That's why we are planing to use it. > Thank you for your solution. I am not sure to follow what you call "Basile's suggestion" exactly. If it is ocamljitrun.c it is just a tiny improvement over interp.c from ocaml distribution. Of course you don't need my permission to use ocamljitrun.c provided you respect its licence and its copyright owner (which is INRIA, which was my employer at the time I wrote it). And after glancing quickly at http://www.ieee.org/membership_services/membership/students/competitions/xtreme/index.html I was not able to easily find mention of a fixed set of languages like C, C#, Java, C++. However, perhaps in reality, your question becomes: what is source code in the eyes of an expert (the human jury of your competition). This don't have any easy or trivial answer. Maybe your answer should take into account the preference of the jury. The definition I usually like the most is that source code is the form of code which is preferred by the programmer (I think it is a GNU definition, or perhaps an FSF one). But again, this could be subject to interpretation, and lawyers or programmers have different views on it. And different programmers have different preferences (just think about the role of comments; there are probably important in your competition, but they don't mean anything to Ocaml.). Source code is not necessarily even a textual file (but in Ocaml or C it usually is; however I could be very pedantic and claim that source code for me is the code picture with syntax hightlighting and colors -as provided by my favorite editor's setting.). Likewise, I am not able to give a precise definition of what a text is (are two different translations or editions of the Bible the same text?). There used to be systems where source code was not textual. Long long time ago, at IRIA (the predecessor of INRIA) there used to be systems like Centaur... I also remember having a read a paper about Galaxy and hypertext programming (forgot the references). Good luck for the competition. Cheers. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} *** ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-09-16 11:11 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-09-14 12:09 Compiling Ocaml sources to c sources Vincent Gripon 2010-09-14 12:16 ` [Caml-list] Compiling Ocaml sources to c sources [NC] Rabih CHAAR 2010-09-14 12:35 ` [Caml-list] Compiling Ocaml sources to c sources David MENTRE 2010-09-15 13:18 ` Vincent Gripon 2010-09-15 19:59 ` Basile Starynkevitch 2010-09-15 22:16 ` Vincent Gripon 2010-09-14 12:43 ` Basile Starynkevitch 2010-09-15 12:59 ` Vincent Gripon 2010-09-15 17:36 ` Jon Harrop 2010-09-15 18:17 ` Eray Ozkural 2010-09-15 20:37 ` Jon Harrop 2010-09-16 0:38 ` Eray Ozkural 2010-09-16 9:05 ` Fabrice Le Fessant 2010-09-16 10:46 ` Eray Ozkural 2010-09-16 11:11 ` Fabrice Le Fessant 2010-09-14 12:47 ` Thomas Gazagnaire 2010-09-14 12:48 ` Grant Rettke 2010-09-15 13:04 ` Vincent Gripon 2010-09-15 19:57 ` Basile Starynkevitch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox