From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBDKdCuv029745 for ; Tue, 13 Dec 2011 21:39:12 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAH23507RVde2kGdsb2JhbABDFqsBCCIBAQEBCQkNBxQEIYFyAQEBAwESAiwBATgECz8SNAEFARwGJwUCB4daAgaYdwqKM4QcAY4SB4sAY6JpPYN5 X-IronPort-AV: E=Sophos;i="4.71,348,1320620400"; d="scan'208";a="135281864" Received: from mail-ey0-f182.google.com ([209.85.215.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Dec 2011 21:39:07 +0100 Received: by eaaf13 with SMTP id f13so138375eaa.27 for ; Tue, 13 Dec 2011 12:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=LCMn4NAEmcNmGR5ZJgQ2F8XH7ejedJb4EUXWcvzCaIM=; b=PdPpQxo//cyHKIHmHH9RFpVSsGXqtBxdybix64rO4KNpAtJb/+3P8jYq05AFXAlfoy Jo8wDpni3wzY18xcifkceH/c82zH7EW/m4/+XFDciCd3ldF4hyHHwONdByBy5AT/vP+D O94Atwda+eEvjxDGzLlShnUDivfMWWyAAM1dA= Received: by 10.204.128.130 with SMTP id k2mr13692114bks.7.1323808746840; Tue, 13 Dec 2011 12:39:06 -0800 (PST) Received: from coruscant.kosmos.all (ip-95-223-170-32.unitymediagroup.de. [95.223.170.32]) by mx.google.com with ESMTPS id j9sm512515bkd.2.2011.12.13.12.39.04 (version=SSLv3 cipher=OTHER); Tue, 13 Dec 2011 12:39:05 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Benedikt Meurer In-Reply-To: <4EE63E88.40805@glondu.net> Date: Tue, 13 Dec 2011 21:39:03 +0100 Message-Id: References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> <4EE63E88.40805@glondu.net> To: caml users X-Mailer: Apple Mail (2.1251.1) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pBDKdCuv029745 Subject: [Caml-list] New experimental ARM backend [was: OCaml maintenance status / community fork (again)] On Dec 12, 2011, at 18:48 , Stéphane Glondu wrote: >>> The relevant bug report PR/5404, which includes a backward >>> compatible patch, is already waiting for a sign of life for 3 weeks >>> now (maybe wait another 4 years to get the port fixed). >> >> More bile. What's so urgent about it? The next release of OCaml is 3-6 >> months in the future; your suggestion will be examined by then. [...] > > It's still unclear to me whether this kind of patches are welcome. I've > been recently approached by an armhf porter (other than Benedikt) > interested in having an ocamlopt running there, but I told him to back > off because I don't know whether needed changes would be merged. Once > again, I don't say we would have come up with a working solution before > the next release of OCaml, but the result (if any) would have already > been tested and deployed in Debian (and/or Ubuntu) before an upstream > submission. 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. Feel free to test the patch, but be aware that it is (a) highly experimental, it's tested and verified to work with Debian armel on ARMv5T and Debian armhf on a Cortex-A8, but YMMV, (b) it only supports ARMv4T+ using the armel ABI w/o VFPv3, Thumb, etc. or ARMv7+ using the armhf ABI w/ VFPv3, Thumb-2, etc., there's no way to choose i.e. armel ABI w/ VFPv3, I don't know whether there's anyone except Ubuntu using such configurations currently, (c) incompatible with .cmx/.cmxa/.cmxs files generated by the old ARM backend, and (d) it's still a bit rough around the edges, i.e. the generated code is usually better (shorter and runs faster), but there's still room for improvement (i.e. instruction selection and scheduling need some more love). Comments and suggestions are welcome. > Cheers, > Stéphane HTH, Benedikt