Maybe switch to using views instead of arrays?
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Tranquilla
- Stack tecnologico
- wasm
- Ambito
- compilers
Direzione di ricerca
Inizia leggendo le issue #3 e #2, quindi confronta il view heap type proposto e l’approccio view.convert_array con l’alternativa di usare array i8 types. Il lavoro è completo quando è stato definito un design per la mutabilità di view, la semantica della conversione, il tipaggio di load/store e per stabilire se array.convert_view rientra nell’ambito.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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:
- 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.
- 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
loadinstructions to work on both mutable and immutable views, andstores would only work on mutable views. - 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.
- 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.
- Lingua principale
- WebAssembly
- Stelle
- 4
- Fork
- 1
- Merge medio
- 16h 35m
- PR unite (30g)
- 1
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di WebAssembly/multibyte-array-access
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
WebAssembly/multibyte-array-access#10 · 1 commento · 1 reazione ·
-
Half precision floatsAperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 50/100
WebAssembly/multibyte-array-access#8 · 1 commento ·
-
Dart SIMD use case.Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
WebAssembly/multibyte-array-access#5 · 13 commenti · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
WebAssembly/multibyte-array-access#3 · 5 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Tutte le issue di WebAssembly/multibyte-array-access
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
I-prioritize needs-triage regression-from-stable-to-beta T-lang
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
rust-lang/rust#163830 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Swift route tables omit digit constraints from generated main and testsForse già presa @dchuk l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
rubys/roundhouse#444 ·
I maintainer di solito rispondono entro 1 giorno
-
IntrinsicLowering::LowerCTPOP runs into assertion with LLVM 23Forse già presa Una pull request collegata a questa issue è aperta o già unita. Apertacrash llvm:codegen
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
llvm/llvm-project#229064 ·
I maintainer di solito rispondono entro 1 giorno
-
area:lowering kind:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno