From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id B1DF282355 for ; Tue, 28 Nov 2017 13:37:42 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=rich@annexia.org; spf=Pass smtp.mailfrom=rich@annexia.org; spf=Pass smtp.helo=postmaster@annexia.org Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of rich@annexia.org) identity=pra; client-ip=80.68.91.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="rich@annexia.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of rich@annexia.org designates 80.68.91.176 as permitted sender) identity=mailfrom; client-ip=80.68.91.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="rich@annexia.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@annexia.org designates 80.68.91.176 as permitted sender) identity=helo; client-ip=80.68.91.176; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rich@annexia.org"; x-sender="postmaster@annexia.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" IronPort-PHdr: =?us-ascii?q?9a23=3APHLacxWNVPpIUUbujWy+hahK8TjV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYZRKGt8tkgFKBZ4jH8fUM07OQ6P+wHzFYqb+681k8M7V0Hycfjs?= =?us-ascii?q?sXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aSV3DMl9+?= =?us-ascii?q?L+HxX4rTlNif1uao+pSVbR8bqiC6ZOY4FhS9rQzLuoEpx64kYoQ2zBbS6DMcYe?= =?us-ascii?q?VdxUthI1Sejxf1oMCq88gwoGxrp/s9+psYAu3BdKMiQOkAAQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzBQDyVx1a/7BbRFBdg22BVCeDNEuZN?= =?us-ascii?q?kABAQEBAQEGgTF+lgSCAQqCAYM6hQRDFAEBAQEBAQEBAQFqKII4IoJFASkPATg?= =?us-ascii?q?BOQMBAgMCBRMOAhEtEQIhihURp1aCJ4swgQ+CLYIJgQ49gXIBgnU2hGwBCwcBA?= =?us-ascii?q?0KCb4JjBYo6jm+JIAKLEEuJI4Ijhg2EB4cllj+BOjYiYXB8CIJjgg4BgkZBNgG?= =?us-ascii?q?IHA8YgiABAQE?= X-IPAS-Result: =?us-ascii?q?A0BzBQDyVx1a/7BbRFBdg22BVCeDNEuZNkABAQEBAQEGgTF?= =?us-ascii?q?+lgSCAQqCAYM6hQRDFAEBAQEBAQEBAQFqKII4IoJFASkPATgBOQMBAgMCBRMOA?= =?us-ascii?q?hEtEQIhihURp1aCJ4swgQ+CLYIJgQ49gXIBgnU2hGwBCwcBA0KCb4JjBYo6jm+?= =?us-ascii?q?JIAKLEEuJI4Ijhg2EB4cllj+BOjYiYXB8CIJjgg4BgkZBNgGIHA8YgiABAQE?= X-IronPort-AV: E=Sophos;i="5.44,468,1505772000"; d="scan'208";a="246357701" Received: from annexia.org ([80.68.91.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 28 Nov 2017 13:37:37 +0100 Received: from rich by annexia.org with local (Exim 4.89) (envelope-from ) id 1eJf8q-0004dL-3m for caml-list@inria.fr; Tue, 28 Nov 2017 12:37:36 +0000 Date: Tue, 28 Nov 2017 12:37:36 +0000 From: "Richard W.M. Jones" To: caml-list@inria.fr Message-ID: <20171128123736.4khsdkli7w6lgqk3@annexia.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: NeoMutt/20170113 (1.7.2) Subject: [Caml-list] Fwd: [ANN] RISC-V J Extension Working Group Forwarding because it may be of interest to the OCaml developers. Rich. - - - Date: Tue, 28 Nov 2017 09:23:55 +0000 From: David Chisnall To: RISC-V HW Dev , RISC-V SW Dev , isa-dev@groups.riscv.org Subject: [sw-dev] [ANN] RISC-V J Extension Working Group Hello RISC-V Developers, We are pleased to announce the formation of the J Extension Working Group (charter attached), chaired by David Chisnall and with Martin Maas as vice chair. This group will be responsible for proposing RISC-V extensions for managed, interpreted and JIT-ed languages that have extend beyond those of ahead-of-time compiled Algol-family languages (such as C/C++). The J working group solicits contributions from hardware implementors, language designers, as well as experts on language-runtime systems, interpreters, compilers, memory management and garbage collection. Contributions in related areas such as dynamic binary translation, memory consistency models and transactional memory are strongly encouraged as well. If you wish to participate, please reply to this email. David Chisnall and Martin Maas RISC-V J Extension Working Group Charter ---------------------------------------- The RISC-V J extension aims to make RISC-V an attractive target for languages that are traditionally interpreted or JIT compiled, or which require large runtime libraries or language-level virtual machines. Examples include (but are not limited to) C#, Go, Haskell, Java, JavaScript, OCaml, PHP, Python, R, Ruby, Scala or WebAssembly. Typical features of these languages include garbage collection, dynamic typing and dynamic dispatch, transparent boxing of primitive values, and reflection. This provides a very wide scope for possible approaches and, as such, the working group will follow a two-pronged strategy investigating both immediate gains and longer-term more experimental ideas concurrently. Existing attempts to implement JIT-compiled languages on RISC-V have highlighted some places where better instruction density is possible, and these should fall into an early version of the specification. Instructions intended to accelerate common JIT’d instruction sequences may be optional within the J extension, with the expectation that software will test for their presence before determining which code sequence to generate. This also provides scope for additions that are only appropriate for a subset of microarchitectures. For example, there is increasing interest in running JavaScript on IoT devices, but acceleration for simple low-power in-order pipelines with constrained memory may be wholly inappropriate for large application cores. Among other topics, the group expects to work within the following areas and collaborate with several existing RISC-V extension working groups: - Dynamic languages often require efficient overflow-checked addition for promotion between integer representations. The M standard describes overflow-checking multiplication, and the J and M extension work groups will work together to unify these. - A significant amount of research has explored hardware support for garbage collection (GC), including hardware read/write barriers and using transactional memory for GC. The J extension group will consider these options and work with a potential future T extension working group to use transactional memory support for this purpose. It is important that the J extension does not propose specialised garbage-collection acceleration support when similar performance can be achieved in software simply by using the T extension. - The memory model working group is refining the core specification’s atomicity and ordering guarantees. Environments containing JIT compilers have stronger requirements with regard to ordering of data writes to instruction reads than traditional ahead-of-time environments (particularly on multicore systems). The J extension may propose a stronger memory model in this regard, but must not propose anything that contradicts the memory model working group’s design. - User-level interrupts have significant potential for side-exits from JIT-compiled code for deoptimisation, certain garbage collection algorithms, and potentially other VM features. User-level interrupts are currently defined in the privileged specification and may be supported by a future N extension. The J working group must coordinate designs with a potential future N working group to ensure that such mechanisms are reusable. The J working group solicits contributions from hardware implementors, language designers, as well as experts on language-runtime systems, interpreters, compilers, memory management and garbage collection. Contributions in related areas such as dynamic binary translation, memory consistency models and transactional memory are strongly encouraged as well.