Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Ocamlopt code generator question
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-05-05 (14:59)
From: Sylvain Le Gall <sylvain@l...>
Subject: Re: Ocamlopt code generator question
On 05-05-2009, Jean-Marc Eber <> wrote:
> Hi Dimitry,
> LexiFi for instance _is_ clearly interested by a sse2 32bit code generator.
> One should probably have the following in mind and/or ask the following questions:
> - it is probably not a good idea to support both backends (sse2 and old stack fp 
> i386 architecture). It will be necessary to make a choice (especially taking in 
> account the limited INRIA resources and the burden of already supporting 
> different windows ports).

Maybe this point can be discussed. I think 3 ports for windows is a bit
too much... I don't know Dimitry point of view, but maybe INRIA can just
consider MSVC (or mingw). If this is a way to free INRIA resources, it
is a good option.

> - would INRIA be ok to switch to a sse2 code generator (based on Dimitry's patch 
>   supposing that he is ok to donate it to INRIA - or Xavier's work or whatever)?
> - I also guess that a sse2 code generator would be simpler than the current one 
> (that has to support this horrible fp stack architecture) and would therefore be 
> a better candidate for further enhancements.
> - what is the opinion on this list, as a switch to a sse2 backend would exclude 
> "old" processors from being OCaml compatible (I don't have a precise list at 
> hand for now) ?

I would like to say "go on", but SSE2 will limit OCaml to P4 on i386.
In Debian, this is the "low limit" of our build daemon. I think it is
quite dangerous not having the option of the older code generator...

If INRIA choose to switch to SSE2 there should be at least still a way
to compile on older architecture. Doesn't mean that INRIA need to keep
the old code generator, but should provide a simple emulation for it. In
this case, we will have good performance on new arch for float and we
will still be able to compile on old arch. 

> My opinion is that this support of legacy hardware is not important, but I guess 
> others are arguing in opposite directions... :-)

I would say that "the performance of legacy hardware is not important"
-- support is still important. 

> But again, having better floating point performance (and predictable behaviour, 
> compared to the bytecode version) would be a big plus for some applications.


Sylvain Le Gall