History log of /wasmtime-44.0.1/pulley/src/opcode.rs (Results 1 – 9 of 9)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7
# 56cae563 30-Mar-2026 Alex Crichton <[email protected]>

Fix `ExtendedOpcode::MAX` for Pulley (#12867)

This was off-by-one which could lead to possible undefined behavior in
Miri and at runtime when disassembling invalid opcodes. This isn't
reachable from

Fix `ExtendedOpcode::MAX` for Pulley (#12867)

This was off-by-one which could lead to possible undefined behavior in
Miri and at runtime when disassembling invalid opcodes. This isn't
reachable from Wasmtime itself since Cranelift only generates valid
opcodes, but it's nonetheless reachable via `wasmtime objdump` and still
good to fix.

show more ...


Revision tags: v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0, v32.0.0
# 073aedab 09-Apr-2025 Alex Crichton <[email protected]>

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)

* Enable the `unsafe-op-in-unsafe-fn` lint

This commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for the
entire workspace. This lint will

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)

* Enable the `unsafe-op-in-unsafe-fn` lint

This commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for the
entire workspace. This lint will be warn-by-default in the 2024 edition
so this is intended to smooth the future migration to the new edition.

Many `unsafe` blocks were added in places the lint warned about, with
two major exceptions. The `wasmtime` and `wasmtime-c-api` crates simply
expect this lint to fire and effectively disable the lint. They're too
big at this time to do through this PR. My hope is that one day in the
future they'll be migrated, but more realistically that probably won't
happen so these crates just won't benefit from this lint.

* Fix nostd fiber build

prtest:full

* Fix build on Windows

* Fix asan build

show more ...


Revision tags: v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0
# c1d405c1 18-Dec-2024 Alex Crichton <[email protected]>

pulley: Shuffle opcodes to free some 1-byte opcodes (#9854)

* pulley: Shuffle opcodes to free some 1-byte opcodes

In the near future the set of opcodes here are going to be expanded
along a number

pulley: Shuffle opcodes to free some 1-byte opcodes (#9854)

* pulley: Shuffle opcodes to free some 1-byte opcodes

In the near future the set of opcodes here are going to be expanded
along a number of axes such as:

* More modes of addressing loads/stores other than just `reg + offset32`.
* Opcodes with immediate operands rather than unconditional register operands.

The 1-byte opcode namespace is already filling up and there's a bit of a
mishmash of what's 1-byte and what's "extended" for now. To help bridge
this gap in the interim shuffle all float/vector-related opcodes into
the "extended" opcode namespace. This frees up a large chunk of the
1-byte opcode namespace for future expansion with extensions like above.

I'll note that I'm not 100% sure that the opcodes will all stay here
after this reshuffling. I haven't done any profiling/performance
analysis to gauge the impact of this change. The immediate goal is to
start experimenting with non-float/vector programs and get them
profiling well. This will require more "macro opcodes" such as new
addressing modes and opcodes-with-immediates. These are expected to be
relatively hot opcodes and thus probably want to be in the "fast" 1-byte
namespace, hence the shuffling here.

My plan is to in the future do a bit of an evaluation with a
float/vector program and see whether it make sense to shuffle some of
them into this 1-bytecode space as well. More radically it might make
sense to remove the split between ops/extended ops and instead just have
a 2-byte opcode space entirely. That's all left for future evaluations
though.

* Fix test offsets

* Update test expectations

show more ...


# 0058cb78 12-Dec-2024 Alex Crichton <[email protected]>

pulley: Get strings.wast test passing (#9801)

* pulley: Get `strings.wast` test passing

Needed the `imul` CLIF instruction to get implemented so 32/64-bit
multiplication have now been added.

cc #

pulley: Get strings.wast test passing (#9801)

* pulley: Get `strings.wast` test passing

Needed the `imul` CLIF instruction to get implemented so 32/64-bit
multiplication have now been added.

cc #9783

* Flag test as now passing

show more ...


# 70a37939 06-Dec-2024 Alex Crichton <[email protected]>

Support executing Pulley in Wasmtime (#9744)

* Support executing Pulley in Wasmtime

This commit is the initial implementation of executing the Pulley
interpreter from the `wasmtime` crate. This gi

Support executing Pulley in Wasmtime (#9744)

* Support executing Pulley in Wasmtime

This commit is the initial implementation of executing the Pulley
interpreter from the `wasmtime` crate. This gives access to all of the
`wasmtime` crate's runtime APIs backed by execution of bytecode in
Pulley. This builds on the previous PRs I've been making for support in
Pulley to culminate in testing on CI in this PR. This PR handles some
final tidbits related to producing a runnable image that can be
interpreted by the `wasmtime` crate such as:

* Pulley compilation artifacts are no longer marked as natively
executable, just read-only.
* Pulley compilation artifacts include wasm-to-array trampolines like
normal platforms (removes a pulley special-case).
* Dispatch of host calls from Pulley to the Wasmtime runtime are
implemented.
* Pulley's list of panicking wasm features is slimmed down as most are
covered by "this lowering isn't supported" errors.
* Execution of wasm code now has an `if` to see whether Pulley is
enabled within a `Store` or not.
* Traps and basic "unwinding" of the pulley stack are implemented (e.g.
a "pulley version" of `setjmp` and `longjmp`, sort of)
* Halting the interpreter has been refactored to help shrink the size of
`ControlFlow<Done>` and handle metadata with each done state.

Some minor refactorings are also included here and there along with a
few fixes here and there necessary to get tests passing.

The next major part of this commit is updates to our `wast` test suite
and executing all `*.wast` files. Pulley is now executed by default for
all files as a new execution engine. This means that all platforms in CI
will start executing Pulley tests. At this time almost all tests are
flagged as "expected to fail" but there are a small handful of
allow-listed tests which are expected to pass. This exact list will
change over time as CLIF lowerings are implemented and the interpreter
is extended.

Follow-up PRs will extend the testing strategy further such as:

* Extending `#[wasmtime_test]` to include Pulley in addition to Winch.
* Getting testing set up on CI for 32-bit platforms.

prtest:full

* Fix pulley fuzz build

* Fix clippy lints

* Shuffle around some `#[cfg]`'d code

* Remove unused imports

* Update feature sets testing MIRI

Enable pulley for wasmtime/wasmtime-cli and also enable all features for
wasmtime-environ

* Round up pulley's page size to 64k

* Skip pulley tests on s390x for now

* Add a safety rail for matching a pulley target to the host

* Fix more pulley tests on s390x

* Review comments

* Fix fuzz build

show more ...


# 5ed60c22 22-Nov-2024 Alex Crichton <[email protected]>

Refactor Pulley's interpreter loop (#9629)

* Refactor Pulley's interpreter loop

* Define loop-over-match and loop-with-tail-calls in separate files to
make it more clear which is in which (and le

Refactor Pulley's interpreter loop (#9629)

* Refactor Pulley's interpreter loop

* Define loop-over-match and loop-with-tail-calls in separate files to
make it more clear which is in which (and less `#[cfg]`)
* Move per-opcode handlers to `interp.rs` outside of a macro invocation
to get better native editor support (e.g. formatting, hints, etc).

This is roughly intended to be perf-neutral but we don't have many
automated benchmarks yet for Pulley so it's intended to profile later as
well.

* Model interpreter as trait implementation

* Add more comments

show more ...


Revision tags: v27.0.0, v26.0.1, v25.0.3, v24.0.2, v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1
# c6da7d8e 01-Oct-2024 Alex Crichton <[email protected]>

Enable Rust's `unused-macro-rules` lint (#9353)

This is allow-by-default in the compiler but looks like it's got a high
fidelity for us where we don't use macros super heavily, so let's try
having i

Enable Rust's `unused-macro-rules` lint (#9353)

This is allow-by-default in the compiler but looks like it's got a high
fidelity for us where we don't use macros super heavily, so let's try
having it enabled.

show more ...


Revision tags: v25.0.1, v25.0.0, v24.0.0, v23.0.2
# ef1ffa2d 25-Jul-2024 Nick Fitzgerald <[email protected]>

Get Pulley tests passing under MIRI; run Pulley tests under MIRI in CI (#9014)

* Pulley: Get tests passing with permissive provenance under MIRI

Co-Authored-By: Alex Crichton <[email protected]

Get Pulley tests passing under MIRI; run Pulley tests under MIRI in CI (#9014)

* Pulley: Get tests passing with permissive provenance under MIRI

Co-Authored-By: Alex Crichton <[email protected]>

* Pulley: Get tests passing with strict provenance in MIRI

Co-Authored-By: Alex Crichton <[email protected]>

* Test Pulley under MIRI in CI

* Test Pulley with all cargo features in CI

* Quiet a warning for certain build configs

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...


# 4ac1bedf 25-Jul-2024 Nick Fitzgerald <[email protected]>

Introduce the `pulley-interpreter` crate (#9008)

* Introduce the `pulley-interpreter` crate

This commit is the first step towards implementing
https://github.com/bytecodealliance/rfcs/pull/35

This

Introduce the `pulley-interpreter` crate (#9008)

* Introduce the `pulley-interpreter` crate

This commit is the first step towards implementing
https://github.com/bytecodealliance/rfcs/pull/35

This commit introduces the `pulley-interpreter` crate which contains the Pulley
bytecode definition, encoder, decoder, disassembler, and interpreter.

This is still very much a work in progress! It is expected that we will tweak
encodings and bytecode definitions, that we will overhaul the interpreter (to,
for example, optionally support the unstable Rust `explicit_tail_calls`
feature), and otherwise make large changes. This is just a starting point to get
the ball rolling.

Subsequent commits and pull requests will do things like add the Cranelift
backend to produce Pulley bytecode from Wasm as well as the runtime integration
to run the Pulley interpreter inside Wasmtime.

* remove stray fn main

* Add small tests for special x registers

* Remove now-unused import

* always generate 0 pc rel offsets in arbitrary

* Add doc_auto_cfg feature for docs.rs

* enable all optional features for docs.rs

* Consolidate `BytecodeStream::{advance,get1,get2,...}` into `BytecodeStream::read`

* fix fuzz targets build

* inherit workspace lints in pulley's fuzz crate

* Merge fuzz targets into one target; fix a couple small fuzz bugs

* Add Pulley to our cargo vet config

* Add pulley as a crate to publish

* Move Pulley fuzz target into top level fuzz directory

show more ...