Stream: git-wasmtime

Topic: wasmtime / issue #4125 Cranelift: generate more from decl...


view this post on Zulip Wasmtime GitHub notifications bot (May 10 2022 at 22:25):

cfallin opened issue #4125:

We currently define an enum to represent machine instructions for each backend. This is fairly high-level and generally nice, allowing us to use Rust types to model arguments and modes, etc.

However, there is a lot of "glue" in the layer of code that supports doing things with these enums that is very tedious and error-prone to write:

Ideally, we could allow the backend author to define a new "assembler library" by:

Then we could generate the rest: essentially the whole implementation of the MachInst trait, or at least most of it.

There has been some informal discussion about whether expanded information about instructions should be in toml/yaml-type files or something else; I believe it might actually be better to keep this in the ISLE, with some sort of annotation syntax, both to reduce the cognitive load of languages that must be learnt, and to keep as few sources-of-truth around as possible.

view this post on Zulip Wasmtime GitHub notifications bot (May 10 2022 at 22:25):

cfallin labeled issue #4125:

We currently define an enum to represent machine instructions for each backend. This is fairly high-level and generally nice, allowing us to use Rust types to model arguments and modes, etc.

However, there is a lot of "glue" in the layer of code that supports doing things with these enums that is very tedious and error-prone to write:

Ideally, we could allow the backend author to define a new "assembler library" by:

Then we could generate the rest: essentially the whole implementation of the MachInst trait, or at least most of it.

There has been some informal discussion about whether expanded information about instructions should be in toml/yaml-type files or something else; I believe it might actually be better to keep this in the ISLE, with some sort of annotation syntax, both to reduce the cognitive load of languages that must be learnt, and to keep as few sources-of-truth around as possible.

view this post on Zulip Wasmtime GitHub notifications bot (May 10 2022 at 22:25):

cfallin labeled issue #4125:

We currently define an enum to represent machine instructions for each backend. This is fairly high-level and generally nice, allowing us to use Rust types to model arguments and modes, etc.

However, there is a lot of "glue" in the layer of code that supports doing things with these enums that is very tedious and error-prone to write:

Ideally, we could allow the backend author to define a new "assembler library" by:

Then we could generate the rest: essentially the whole implementation of the MachInst trait, or at least most of it.

There has been some informal discussion about whether expanded information about instructions should be in toml/yaml-type files or something else; I believe it might actually be better to keep this in the ISLE, with some sort of annotation syntax, both to reduce the cognitive load of languages that must be learnt, and to keep as few sources-of-truth around as possible.

view this post on Zulip Wasmtime GitHub notifications bot (May 10 2022 at 22:25):

cfallin labeled issue #4125:

We currently define an enum to represent machine instructions for each backend. This is fairly high-level and generally nice, allowing us to use Rust types to model arguments and modes, etc.

However, there is a lot of "glue" in the layer of code that supports doing things with these enums that is very tedious and error-prone to write:

Ideally, we could allow the backend author to define a new "assembler library" by:

Then we could generate the rest: essentially the whole implementation of the MachInst trait, or at least most of it.

There has been some informal discussion about whether expanded information about instructions should be in toml/yaml-type files or something else; I believe it might actually be better to keep this in the ISLE, with some sort of annotation syntax, both to reduce the cognitive load of languages that must be learnt, and to keep as few sources-of-truth around as possible.

view this post on Zulip Wasmtime GitHub notifications bot (May 10 2022 at 23:04):

abrown commented on issue #4125:

I think this would be a good idea (I've had it in the past but it seems like a lot of work). I think an advantage of this is that it would make it easier to refactor the x64 Inst variants to more closely align with the ISA instructions; IMO, it is not always clear how to encode an instruction given the current "classes of instructions" available. If this issue were implemented with a way to template the shapes of instructions (e.g., <hole> xmm, xmm/m128) then it would be possible to generate Inst variants that match the ISA.


Last updated: Dec 23 2024 at 12:05 UTC