From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id D4D56BBAF for ; Tue, 5 May 2009 17:59:36 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAKf//0lIDtydkGdsb2JhbACWOD8BAQEBCQkMBxEDqFqBCiwIj3wBAwEDgisaCIExBQ X-IronPort-AV: E=Sophos;i="4.40,298,1238968800"; d="scan'208";a="39490955" Received: from fg-out-1718.google.com ([72.14.220.157]) by mail4-smtp-sop.national.inria.fr with ESMTP; 05 May 2009 17:59:36 +0200 Received: by fg-out-1718.google.com with SMTP id l26so1379684fgb.2 for ; Tue, 05 May 2009 08:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=gNzJYBwMTu0OWMaE0GAmFZtzU1IZ+cbU7RrWxX5Vc+k=; b=RghOB2UpN8DEsEUM8bZl1Hdy63M1XKGOaze0eY8Yf/r5eXX1RCeH0oVRItoKvFLlVY JXKTs45gH5/ZarDEjKTYpINJwI8av5SoKC3o1KDrF9JeGHr7wKz3EV0Z7tcNRYTu1EQA EtMLkJ+PZoSJaI+CEDx1AC77ncKNJRr//7EZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ZDQWSqyqXoIYfw+cjAO7j7+WoiJrgrwNAh98nQKj6YaeC/m4wSK9bx5yH+xaXQM/e8 NA5KYcFfZEPd5F4IShcCNMp0jE6fXYDHOe2+5avja0bmQPTHsQgzklCMPSYhPq9Yw+5i YfcJVscbkfSIYhHZ2Ss4X8AhZa1+cxcW8OyFg= MIME-Version: 1.0 Received: by 10.143.1.12 with SMTP id d12mr68024wfi.203.1241539174945; Tue, 05 May 2009 08:59:34 -0700 (PDT) In-Reply-To: References: <90823c940904281236x61204451nac149ee15b5df73a@mail.gmail.com> <4A0005C8.8010609@inria.fr> <90823c940905050241y11f012e5xee8316e3e4337ff9@mail.gmail.com> <4A004A05.6040204@lexifi.com> Date: Tue, 5 May 2009 19:59:34 +0400 Message-ID: <90823c940905050859q4c203894k5410a7625fe9b2b3@mail.gmail.com> Subject: Re: [Caml-list] Re: Ocamlopt code generator question From: Dmitry Bely To: Caml List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; ocamlopt:01 le-gall:01 lexifi:01 lexifi:01 mingw:01 cygwin:01 runtime:01 makefiles:01 ocaml:01 bug:01 mingw:01 mlp:01 mlp:01 masm:01 syntax:01 On Tue, May 5, 2009 at 6:58 PM, Sylvain Le Gall wrote= : > On 05-05-2009, Jean-Marc Eber wrote: >> Hi Dimitry, >> >> LexiFi for instance _is_ clearly interested by a sse2 32bit code generat= or. >> >> 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 ta= king 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 >> =A0 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 curr= ent one >> (that has to support this horrible fp stack architecture) and would ther= efore 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 lis= t 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 beh= aviour, >> compared to the bytecode version) would be a big plus for some applicati= ons. >> > > 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