Re: [Caml-list] Re: Ocamlopt code generator question

[Dmitry Bely <dmitry.bely@gmail.com>]

On Tue, May 5, 2009 at 6:58 PM, Sylvain Le Gall <sylvain@le-gall.net> wrote:
> On 05-05-2009, Jean-Marc Eber <jeanmarc.eber@lexifi.com> 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.

You should ask Xavier but I personally don't think that two Windows
ports (Cygwin is quite a different beast) are really the problem for
INRIA. They use (almost) the same C runtime library, the same
makefiles and I don't know a single Ocaml bug that was MSVC or Mingw
specific.

Yes, you have two different emit_nt.mlp and emit.mlp, but the only way
to make things simpler is to abandon MASM syntax completely. In
principle it's possible - GNU as under Windows generates the same COFF
files as MASM, although many Windows people that are not familiar with
AT&T syntax would not be very glad...

>> - 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...

I also would like to retain support for i386. Hopefully, one more code
generator (mostly a copy/paste combination of two already existing
ones) would not require too much efforts to support.

> 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.
>>
>
> Indeed.

Don't quite understand what is "predictable behavior" - any generator
should conform to specs. In my tests x87 and SSE2 backends show the
same results (otherwise it would be called a bug).

- Dmitry Bely