Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Maybe switch to using views instead of arrays?

オープン
  • 何か問題がありますか？
#4 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
wasm
領域
compilers

調査の方向性

まず issue #3 と #2 を読み、提案されている view heap type と view.convert_array アプローチを、array i8 types を使用する代替案と比較してください。完了条件は、view の可変性、変換セマンティクス、load/store の型付け、および array.convert_view を対象範囲に含めるかどうかについて、設計方針が決定されていることです。

索引モデルが issue の本文から書いたものです。

説明

If we were to implement my suggestion for supporting all numeric array types, I thought it could be useful to introduce a new view heap type that could represent untyped binary data, and make the load/store instructions work on view types instead of array types.

To facilitate this, a new instruction along the lines of view.convert_array would need to be added, which converts a numeric array type to a view. The view type would be an immediate subtype of eq and a sibling type to array. There would be both mutable and immutable views, depending on the mutability of the array they were converted from. The view would point to the same underlying memory as the array type it was converted from, and the conversion should be done in constant time.

I feel this has several advantages compared to working with arrays directly:

  1. If my suggestion for supporting all numeric array types were to be implemented, code may need to branch depending on the array type to use the instruction with the correct immediate type, even though the underlying logic and semantics are the same.
  2. This would make the binary format simpler, because instead of having a type immediate in the instruction, we could simply reserve another bit in memarg to denote whether the view is mutable or not. This might turn out to not even be necessary, because the semantics could allow for load instructions to work on both mutable and immutable views, and stores would only work on mutable views.
  3. This would also resolve the question regarding 8-bit accesses, because since we would no longer be working with arrays, they would be needed anyway.
  4. While not strictly necessary for this proposal, we could add another instruction like array.convert_view, which would complete the loop and effectively allow reinterpret-casting of numeric arrays, e.g. (array (mut f32)) -> (view (mut)) -> (array (mut i32)). This is not currently possible, as the gc proposal does not allow for casting between any two array types. Note that this would not replace the functionality of this proposal: array indexing only supports aligned loads and stores, while this proposal supports unaligned accesses, as well as SIMD load/store instructions with more complicated semantics, e.g. v128.store8_lane, v128.load32x2_u, v128.load16_splat, etc.

If it turns out that adding a new view heap type would be too complicated or would slow down this proposal, we could alternatively continue using the (array i8) and (array (mut i8)) types, and I think most of the advantages I described above would still apply.

Let me know what you think about this @brendandahl.

主要言語
WebAssembly
スター
4
フォーク
1
平均マージ
16時間 35分
マージ済み PR（30日）
1

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

WebAssembly/multibyte-array-access のほかの issue

WebAssembly/multibyte-array-access の issue をすべて見る

似ている issue

Compilers の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。