wasmtime / issue #4126 Cranelift: make authoring a new ma... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #4126 Cranelift: make authoring a new ma...

Wasmtime GitHub notifications bot (May 10 2022 at 22:33):

Currently, adding a new backend to Cranelift entails at least the following:

Defining an "assembler library" centered on a new MachInst type, with all the tedious and error-prone work around that (see #4125);

Defining the register set;

Defining glue constructors in ISLE to generate these instructions;

Defining lowering rules in ISLE;

Implementing top-level driver logic for the ISLE backend;

Implementing a bunch of miscellaneous traits and types, such as the LabelUse relocation framework;

Implementing an ABI binding;

Implementing unwind info and debuginfo specifics for this platform;

implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).

While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.

In particular:

Solving #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;

Generating ISLE constructors for the machine instructions automatically would help a lot;

Providing "default implementations" for a lot of the MachBackend trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.

Wasmtime GitHub notifications bot (May 10 2022 at 22:33):

cfallin labeled issue #4126:

Currently, adding a new backend to Cranelift entails at least the following:

Defining an "assembler library" centered on a new MachInst type, with all the tedious and error-prone work around that (see #4125);

Defining the register set;

Defining glue constructors in ISLE to generate these instructions;

Defining lowering rules in ISLE;

Implementing top-level driver logic for the ISLE backend;

Implementing a bunch of miscellaneous traits and types, such as the LabelUse relocation framework;

Implementing an ABI binding;

Implementing unwind info and debuginfo specifics for this platform;

implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).

While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.

In particular:

Solving #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;

Generating ISLE constructors for the machine instructions automatically would help a lot;

Providing "default implementations" for a lot of the MachBackend trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.

Wasmtime GitHub notifications bot (May 10 2022 at 22:33):

cfallin labeled issue #4126:

Currently, adding a new backend to Cranelift entails at least the following:

Defining an "assembler library" centered on a new MachInst type, with all the tedious and error-prone work around that (see #4125);

Defining the register set;

Defining glue constructors in ISLE to generate these instructions;

Defining lowering rules in ISLE;

Implementing top-level driver logic for the ISLE backend;

Implementing a bunch of miscellaneous traits and types, such as the LabelUse relocation framework;

Implementing an ABI binding;

Implementing unwind info and debuginfo specifics for this platform;

implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).

While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.

In particular:

Solving #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;

Generating ISLE constructors for the machine instructions automatically would help a lot;

Providing "default implementations" for a lot of the MachBackend trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.

Wasmtime GitHub notifications bot (May 10 2022 at 22:33):

cfallin labeled issue #4126:

Currently, adding a new backend to Cranelift entails at least the following:

Defining an "assembler library" centered on a new MachInst type, with all the tedious and error-prone work around that (see #4125);

Defining the register set;

Defining glue constructors in ISLE to generate these instructions;

Defining lowering rules in ISLE;

Implementing top-level driver logic for the ISLE backend;

Implementing a bunch of miscellaneous traits and types, such as the LabelUse relocation framework;

Implementing an ABI binding;

Implementing unwind info and debuginfo specifics for this platform;

implementing whatever is necessary in the Cranelift embedder (e.g. for wasmtime, at least the fiber support, trap handling details, and object-file details like relocations).

While some of this is unavoidable, we should strive as much as possible to factor out the commonalities, and centralize things otherwise, and write documentation walking through the whole process.

In particular:

Solving #4125 would allow the backend author to follow a declarative approach to sketch the instruction format, then "chase the type errors" to fill out the emission details, without too much fear of mistakes in the glue;

Generating ISLE constructors for the machine instructions automatically would help a lot;

Providing "default implementations" for a lot of the MachBackend trait, and factoring out the rest into smaller traits, would eliminate a lot of the duplication that currently exists.

Last updated: Nov 22 2024 at 17:03 UTC