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 <[email protected]> wrote: > [email protected] 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 > -- 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
