From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBE9Ipvb021559 for ; Wed, 14 Dec 2011 10:18:51 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8AAPpo6E4machwl2dsb2JhbABDFqszAQEBAQEIFgc5gXIBAQU6PxALGCMLFEknh263HYsmYwSUc5Iq X-IronPort-AV: E=Sophos;i="4.71,351,1320620400"; d="scan'208";a="123302076" Received: from mx1.janestreet.com (HELO nyc-dmz-mxout1.janestreet.com) ([38.105.200.112]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2011 10:18:45 +0100 Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57]) by nyc-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1Rakz6-0005nS-9C for caml-list@inria.fr; Wed, 14 Dec 2011 04:18:44 -0500 Received: from nyc-qsv-004.delacy.com ([172.25.22.194] helo=qsmtp.delacy.com) by nyc-qsv-mail1.delacy.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Rakz6-00030V-7Y; Wed, 14 Dec 2011 04:18:44 -0500 Received: from ldn-qws-r03.delacy.com ([172.23.65.103]) by qsmtp.delacy.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Rakz5-00067Q-VH; Wed, 14 Dec 2011 04:18:44 -0500 Received: from mshinwell by ldn-qws-r03.delacy.com with local (Exim 4.71) (envelope-from ) id 1Rakz5-0000gG-9m; Wed, 14 Dec 2011 09:18:43 +0000 Date: Wed, 14 Dec 2011 09:18:43 +0000 From: Mark Shinwell To: Benedikt Meurer Cc: caml users Message-ID: <20111214091843.GA26813@janestreet.com> References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> <4EE63E88.40805@glondu.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-JS-Compliance: sender=unverified recipient=caml-list (ld) X-Validation-by: mshinwell@janestreet.com Subject: Re: [Caml-list] New experimental ARM backend [was: OCaml maintenance status / community fork (again)] On Tue, Dec 13, 2011 at 09:39:03PM +0100, Benedikt Meurer wrote: > You can grab my current patch for the new OCaml ARM backend at: > > http://ps.informatik.uni-siegen.de/~meurer/tmp/ocaml-arm-20111213.diff > > Compared to the old backend, this one does the following: > > - Support for both softfp and VFPv3-D16 (if present). > - Properly supports interworking with Thumb/Thumb-2 code (for both OCaml and C code!) > - Supports dynamic linking and large memory models. > - Optional support for position-independent code via -fPIC, disabled by default and not required for natdynlink. > - Can emit both ARM and Thumb-2 code (currently Thumb-2 is used for ARMv7+ and ARM is used for everything else), with avg. code size savings of 27% for Thumb-2 (quite close the optimal 30% advertised by ARM Ltd.). I may also add support to emit small functions using Thumb-1 (for pre-ARMv7 / armel) in the future to reduce code size. > - Supports both AAPCS (armel) as well as extended VFP calling conventions (armhf). > - Properly supports backtraces. > - Recognizes several special ARM instructions (=> reduced code size and latency). > - Does not rely on GCC internals, but uses the standard ARM EABI runtime. Dear Benedikt, This looks like an impressive amount of work. I'd like to suggest that a good approach to getting some/all of this merged might be to divide the patch up into smaller units each addressing a particular deficiency or implementing a particular feature. In that way it should be more straightforward to understand the effects on the whole system of each particular patch and maintain stability and compatibility. I understand that this might cause some work and that some of the patches might be intertwined. (Another approach might be to introduce this backend as a second ARM backend with the understanding that it may be experimental to a certain extent---but I think that's less satisfactory, and less likely to find favour with everyone.) Which items from the above list would you most like to see in the core distribution? I would have thought the basic VFP support was fairly high up the list. Mark