Skip to content

[spec] Describe backwards-compatibility and reserve 0xFF opcode #1900

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Parent: Update testharness.js from upstream.
merged 4 commits into from
May 20, 2025
Merged

[spec] Describe backwards-compatibility and reserve 0xFF opcode #1900

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
3880f78
[spec] Describe backwards-compatibility and reserve 0xFF opcode
rossberg May 8, 2025
160a5f7
Reword
rossberg May 8, 2025
db0e3b6
Clarify changes to text format
rossberg May 9, 2025
70791c4
More comments
rossberg May 9, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions document/core/appendix/changes.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,39 @@ Change History
Since the original release 1.0 of the WebAssembly specification, a number of proposals for extensions have been integrated.
The following sections provide an overview of what has changed.

All present and future versions of WebAssembly are intended to be *backwards-compatible* with all previous versions.
Concretely:

1. All syntactically :ref:`well-formed <binary>` and :ref:`valid <valid>` modules remain well-formed and valid with an equivalent :ref:`module type <syntax-moduletype>` (or a subtype).

.. note::
This allows previously malformed or invalid modules to become legal,
e.g., by adding new features or by relaxing typing rules.

It also allows reclassifying previously malformed modules as well-formed but invalid,
or vice versa.

And it allows refining the typing of :ref:`imports <syntax-import>` and :ref:`exports <syntax-export>`,
such that previously unlinkable modules become linkable.

2. All non-:ref:`trapping <trap>` :ref:`executions <exec>` of a valid program retain their behaviour with an equivalent set of possible :ref:`results <syntax-result>` (or a non-empty subset).

.. note::
This allows previously illegal programs to become executable.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is meant by "illegal" here? Is there a more precise word we can use? "Invalid?"

Copy link
Member Author

@rossberg rossberg May 9, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Malformed or invalid. I expanded it.


It also allows program executions that previously trapped to execute successfully.
Copy link
Contributor

@titzer titzer May 8, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this point. Have we utilized this to extend semantics to date?

One reason to avoid that is that trapping is observable in an embedding context, and both Wasm programs and embedded environments can use trapping operations as security checks; i.e. a program won't continue past a divide by zero or and out-of-bounds memory access in an unanticipated state.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we have used it yet, but I believe we have implicitly assumed that we could on a few occasions. I have recollections of design discussions where trapping was suggested as a conservative design choice for cases we don't know how to deal best with yet, e.g. due to possibly unknown future constraints. The answer of starting out with trapping for such cases implies that the trap could be lifted later.

We should definitely use this option rarely and carefully and only in cases where we previously documented that certain trapping cases might have legal behaviour in the future. But shutting out the possibility entirely would eliminate a valuable tool for incremental feature introduction.

Moreover, the same reasoning would apply to relaxing typing, just that it's affecting assumptions about static rather than dynamic failure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems useful to at least guarantee (if we can make such guarantees) that at least some traps will never be lifted, at the very least for the unreachable instruction.

Would it be feasible to include this sense of "cases where we previously documented that certain trapping cases might have legal behaviour in the future" in the text here, and limit the guarantee to that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a qualification along these lines.


And it allows reducing the set of observable behaviours of a program execution,
e.g., by reducing non-determinism.

In a program linking prior modules with modules using new features,
a prior module may encounter new behaviours,
e.g., new forms of control flow or side effects when calling into a latter module.

In addition, the :ref:`instruction opcode <binary-instr>` :math:`\hex{FF}` is considered reserved for custom use and will never be allocated to represent an instruction or instruction prefix.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we say "future versions of the spec will not allocate 0xFF to a valid opcode"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, reworded.




Release 2.0
~~~~~~~~~~~

Expand Down
1 change: 1 addition & 0 deletions document/core/valid/modules.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -729,6 +729,7 @@ Imports :math:`\import` and import descriptions :math:`\importdesc` are classifi
pair: validation; module
single: abstract syntax; module
.. _valid-module:
.. _syntax-moduletype:

Modules
~~~~~~~
Expand Down
Loading