[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
