[Caml-list] Fwd: [ANN] RISC-V J Extension Working Group

[Caml-list] Fwd: [ANN] RISC-V J Extension Working Group

[Richard W.M. Jones]

Forwarding because it may be of interest to the OCaml developers.

Rich.

	- - -

Date: Tue, 28 Nov 2017 09:23:55 +0000
From: David Chisnall <David.Chisnall@cl.cam.ac.uk>
To: RISC-V HW Dev <hw-dev@groups.riscv.org>, RISC-V SW Dev
	<sw-dev@groups.riscv.org>, 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.