Skip to content

Commit e6bdf1e

Browse files
committed
add wasm64 support
1 parent 6cec76b commit e6bdf1e

File tree

7 files changed

+26
-117
lines changed

7 files changed

+26
-117
lines changed

crates/core_arch/src/core_arch_docs.md

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -191,6 +191,7 @@ others at:
191191
* [`powerpc64`]
192192
* [`nvptx`]
193193
* [`wasm32`]
194+
* [`wasm64`]
194195

195196
[`x86`]: x86/index.html
196197
[`x86_64`]: x86_64/index.html
@@ -201,7 +202,8 @@ others at:
201202
[`powerpc`]: powerpc/index.html
202203
[`powerpc64`]: powerpc64/index.html
203204
[`nvptx`]: nvptx/index.html
204-
[`wasm32`]: wasm32/index.html
205+
[`wasm32`]: wasm/index.html
206+
[`wasm64`]: wasm/index.html
205207

206208
# Examples
207209

crates/core_arch/src/lib.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@
4141
bench_black_box
4242
)]
4343
#![cfg_attr(test, feature(test, abi_vectorcall))]
44-
#![cfg_attr(all(test, target_arch = "wasm32"), feature(wasm_simd))]
44+
#![cfg_attr(all(test, target_arch = "wasm32", target_arch = "wasm64"), feature(wasm_simd))]
4545
#![deny(clippy::missing_inline_in_public_items)]
4646
#![allow(
4747
clippy::inline_always,

crates/core_arch/src/mod.rs

Lines changed: 16 additions & 109 deletions
Original file line numberDiff line numberDiff line change
@@ -58,117 +58,24 @@ pub mod arch {
5858

5959
/// Platform-specific intrinsics for the `wasm32` platform.
6060
///
61-
/// This module provides intrinsics specific to the WebAssembly
62-
/// architecture. Here you'll find intrinsics specific to WebAssembly that
63-
/// aren't otherwise surfaced somewhere in a cross-platform abstraction of
64-
/// `std`, and you'll also find functions for leveraging WebAssembly
65-
/// proposals such as [atomics] and [simd].
66-
///
67-
/// Intrinsics in the `wasm32` module are modeled after the WebAssembly
68-
/// instructions that they represent. All functions are named after the
69-
/// instruction they intend to correspond to, and the arguments/results
70-
/// correspond to the type signature of the instruction itself. Stable
71-
/// WebAssembly instructions are [documented online][instrdoc].
72-
///
73-
/// [instrdoc]: https://webassembly.github.io/spec/core/valid/instructions.html
74-
///
75-
/// If a proposal is not yet stable in WebAssembly itself then the functions
76-
/// within this function may be unstable and require the nightly channel of
77-
/// Rust to use. As the proposal itself stabilizes the intrinsics in this
78-
/// module should stabilize as well.
79-
///
80-
/// [atomics]: https://github.com/webassembly/threads
81-
/// [simd]: https://github.com/webassembly/simd
82-
///
83-
/// See the [module documentation](../index.html) for general information
84-
/// about the `arch` module and platform intrinsics.
85-
///
86-
/// ## Atomics
87-
///
88-
/// The [threads proposal][atomics] for WebAssembly adds a number of
89-
/// instructions for dealing with multithreaded programs. Most instructions
90-
/// added in the [atomics] proposal are exposed in Rust through the
91-
/// `std::sync::atomic` module. Some instructions, however, don't have
92-
/// direct equivalents in Rust so they're exposed here instead.
93-
///
94-
/// Note that the instructions added in the [atomics] proposal can work in
95-
/// either a context with a shared wasm memory and without. These intrinsics
96-
/// are always available in the standard library, but you likely won't be
97-
/// able to use them too productively unless you recompile the standard
98-
/// library (and all your code) with `-Ctarget-feature=+atomics`.
99-
///
100-
/// It's also worth pointing out that multi-threaded WebAssembly and its
101-
/// story in Rust is still in a somewhat "early days" phase as of the time
102-
/// of this writing. Pieces should mostly work but it generally requires a
103-
/// good deal of manual setup. At this time it's not as simple as "just call
104-
/// `std::thread::spawn`", but it will hopefully get there one day!
105-
///
106-
/// ## SIMD
107-
///
108-
/// The [simd proposal][simd] for WebAssembly adds a new `v128` type for a
109-
/// 128-bit SIMD register. It also adds a large array of instructions to
110-
/// operate on the `v128` type to perform data processing. The SIMD proposal
111-
/// at the time of this writing is in [phase 4] which means that it's in the
112-
/// standardization phase. It's expected that once some testing on nightly
113-
/// has happened a stabilization proposal will be made for the Rust
114-
/// intrinsics. If you notice anything awry please feel free to [open an
115-
/// issue](https://github.com/rust-lang/stdarch/issues/new).
116-
///
117-
/// [phase 4]: https://github.com/webassembly/proposals
118-
///
119-
/// Using SIMD is intended to be similar to as you would on `x86_64`, for
120-
/// example. You'd write a function such as:
121-
///
122-
/// ```rust,ignore
123-
/// #[cfg(target_arch = "wasm32")]
124-
/// #[target_feature(enable = "simd128")]
125-
/// unsafe fn uses_simd() {
126-
/// use std::arch::wasm32::*;
127-
/// // ...
128-
/// }
129-
/// ```
130-
///
131-
/// Unlike `x86_64`, however, WebAssembly does not currently have dynamic
132-
/// detection at runtime as to whether SIMD is supported (this is one of the
133-
/// motivators for the [conditional sections][condsections] and [feature
134-
/// detection] proposals, but that is still pretty early days). This means
135-
/// that your binary will either have SIMD and can only run on engines
136-
/// which support SIMD, or it will not have SIMD at all. For compatibility
137-
/// the standard library itself does not use any SIMD internally.
138-
/// Determining how best to ship your WebAssembly binary with SIMD is
139-
/// largely left up to you as it can can be pretty nuanced depending on
140-
/// your situation.
141-
///
142-
/// [condsections]: https://github.com/webassembly/conditional-sections
143-
/// [feature detection]: https://github.com/WebAssembly/feature-detection
144-
///
145-
/// To enable SIMD support at compile time you need to do one of two things:
146-
///
147-
/// * First you can annotate functions with `#[target_feature(enable =
148-
/// "simd128")]`. This causes just that one function to have SIMD support
149-
/// available to it, and intrinsics will get inlined as usual in this
150-
/// situation.
151-
///
152-
/// * Second you can compile your program with `-Ctarget-feature=+simd128`.
153-
/// This compilation flag blanket enables SIMD support for your entire
154-
/// compilation. Note that this does not include the standard library
155-
/// unless you [recompile the standard library][buildstd].
156-
///
157-
/// [buildstd]: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#build-std
158-
///
159-
/// If you enable SIMD via either of these routes then you'll have a
160-
/// WebAssembly binary that uses SIMD instructions, and you'll need to ship
161-
/// that accordingly. Also note that if you call SIMD intrinsics but don't
162-
/// enable SIMD via either of these mechanisms, you'll still have SIMD
163-
/// generated in your program. This means to generate a binary without SIMD
164-
/// you'll need to avoid both options above plus calling into any intrinsics
165-
/// in this module.
61+
/// See the [module documentation](../index.html) for more details.
16662
#[cfg(any(target_arch = "wasm32", doc))]
16763
#[doc(cfg(target_arch = "wasm32"))]
16864
#[stable(feature = "simd_wasm32", since = "1.33.0")]
16965
pub mod wasm32 {
17066
#[stable(feature = "simd_wasm32", since = "1.33.0")]
171-
pub use crate::core_arch::wasm32::*;
67+
pub use crate::core_arch::wasm::*;
68+
}
69+
70+
/// Platform-specific intrinsics for the `wasm64` platform.
71+
///
72+
/// See the [module documentation](../index.html) for more details.
73+
#[cfg(any(target_arch = "wasm64", doc))]
74+
#[doc(cfg(target_arch = "wasm64"))]
75+
#[stable(feature = "", since = "0.0.0")]
76+
pub mod wasm64 {
77+
#[stable(feature = "", since = "0.0.0")]
78+
pub use crate::core_arch::wasm::*;
17279
}
17380

17481
/// Platform-specific intrinsics for the `mips` platform.
@@ -238,9 +145,9 @@ mod aarch64;
238145
#[doc(cfg(any(target_arch = "arm")))]
239146
mod arm;
240147

241-
#[cfg(any(target_arch = "wasm32", doc))]
242-
#[doc(cfg(target_arch = "wasm32"))]
243-
mod wasm32;
148+
#[cfg(any(target_arch = "wasm32", target_arch = "wasm64", doc))]
149+
#[doc(cfg(any(target_arch = "wasm32", target_arch = "wasm64")))]
150+
mod wasm;
244151

245152
#[cfg(any(target_arch = "mips", target_arch = "mips64", doc))]
246153
#[doc(cfg(any(target_arch = "mips", target_arch = "mips64")))]

crates/core_arch/src/wasm32/memory.rs renamed to crates/core_arch/src/wasm/memory.rs

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -2,10 +2,10 @@
22
use stdarch_test::assert_instr;
33

44
extern "C" {
5-
#[link_name = "llvm.wasm.memory.grow.i32"]
6-
fn llvm_memory_grow(mem: u32, pages: i32) -> i32;
7-
#[link_name = "llvm.wasm.memory.size.i32"]
8-
fn llvm_memory_size(mem: u32) -> i32;
5+
#[link_name = "llvm.wasm.memory.grow"]
6+
fn llvm_memory_grow(mem: u32, pages: isize) -> isize;
7+
#[link_name = "llvm.wasm.memory.size"]
8+
fn llvm_memory_size(mem: u32) -> isize;
99
}
1010

1111
/// Corresponding intrinsic to wasm's [`memory.size` instruction][instr]
@@ -51,6 +51,6 @@ pub fn memory_size<const MEM: u32>() -> usize {
5151
pub fn memory_grow<const MEM: u32>(delta: usize) -> usize {
5252
unsafe {
5353
static_assert!(MEM: u32 where MEM == 0);
54-
llvm_memory_grow(MEM, delta as i32) as isize as usize
54+
llvm_memory_grow(MEM, delta as isize) as usize
5555
}
5656
}

crates/core_arch/src/wasm32/mod.rs renamed to crates/core_arch/src/wasm/mod.rs

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
//! WASM32 intrinsics
1+
//! WebAssembly intrinsics
22
33
#[cfg(test)]
44
use stdarch_test::assert_instr;

0 commit comments

Comments
 (0)