Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Overloading of RMW and wait operations

Aperta
  • Qualcosa non va?
#114 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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 la revisione della pull request collegata e la discussione riassunta della riunione del CG. Confronta le preoccupazioni sull’interprete sollevate dai partecipanti con le attuali operazioni RMW e wait sovraccariche. Il lavoro è completato solo quando è stata presa una decisione di progettazione condivisa sul mantenere o rimuovere la regola che vieta il sovraccarico, anziché limitarsi a una modifica localizzata del codice.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

As @rossberg brought up in https://github.com/WebAssembly/shared-everything-threads/pull/110#pullrequestreview-4080081246 and as we discussed at the recent CG meeting, the current design overloads the new RMW and wait operations to work with several types. For example struct.atomic.rmw.add x y works on both i32 and i64 fields. This does not violate our principal types properties because the type of the field is determined by the type and field immediates x and y. However, the execution of the instruction needs to handle addition on both i32 and i64 fields in a way we have historically avoided, by e.g. making i32.add and i64.add separate instructions. (Although it is the case that separating i32.add and i64.add is necessary to preserve principal types as well.)

The "no overloading" rule is also already somewhat fuzzy in practice. Instructions like ref.is_null are parametric over all heap types, so need to handle comparisons with potentially different null values and representations for each heap type hierarchy. Instructions like struct.get obviously have different implementations for different field types in real implementations, even if the spec can be written to handle all types generically.

So I argue that the "no overloading" rule is not buying us much in practice, and it would be well worth dropping it to reduce the need to introduce dozens of new instructions. We won't immediately descend into chaos because we still have the principal types properties imposing order on the instruction set.

In the CG meeting, @titzer raised the point that in-place interpreters need to do extra work when instructions are overloaded. @kmiller68 said he would have to go see how this would affect the JSC interpreter. My question is: given that these interpreters already have to handle e.g. struct.get, is it really worth adding dozens of instructions to save them this work on instructions that will be much less common than struct.get?

Lingua principale
WebAssembly
Stelle
97
Fork
7
Merge medio
1g 20h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di WebAssembly/shared-everything-threads

Tutte le issue di WebAssembly/shared-everything-threads

Issue simili

Altre issue su Compilers

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.