float atomics, i64 atomics, i64.wait

[binji]

The current proposal differs from the JS SharedArrayBuffers spec, by allowing float atomic operations (just fxx.atomic.store and fxx.atomic.load), 64-bit integer atomic operations, and i64.wait. Are these desired?

[lars-t-hansen]

64-bit integer atomics are desirable IMO. Float atomics fell out of the initial round for ES due to general opposition and unclear motivation (plus you can make your own non-lock-free float atomics). IMO they are "nice to have" and once the machinery is there for 64-bit atomics (which are not lock free on eg MIPS32 and on some ARMv7 IIRC) the floats are not particularly hard to implement. So why not.

I sort of see the motivation for i64.wait but I am less certain that it is MVP-worthy.

Also, can you have i64.wait without i64.wake? I suppose so, from one point of view the address passed to i32.wake is just an identifier, the memory is not read or written, but I'm not 100% sure that there aren't plausible implementation techniques of wait/wake that would not somehow actually depend on the word width...

[binji]

I sort of see the motivation for i64.wait but I am less certain that it is MVP-worthy.

Agreed. But it also seems like a strange omission of we have 64-bit atomics.

Also, can you have i64.wait without i64.wake?

I think so, for the reasons you've described. But, yeah, it's worth discussing whether we'll want matching wake ops.

[lars-t-hansen]

Just remembered that wasm has the reinterpret instructions, so really we don't need float atomics in the way that JS might have needed float atomics - in wasm we can just move the data into the integer space, do atomics in that space, and move the data back again. After all, that's what the implementation would do anyway, no system I've seen has float atomics in hardware.

[jfbastien]

no system I've seen has float atomics in hardware.

I expect this to be incorrect. It is also being proposed for C++20. The question would then be what's the gain? Extra encoding versus convenience? FWIW LLVM used to have no FP atomics, and does as of a year or two ago.

Not a big argument to be sure.

[lars-t-hansen]

I'm probably just feeling pedantic this morning, but really, no system I've seen has float atomics in hardware. I bet no system you've seen has them either, or you would have cited at least one counterexample.

As you say, I don't think there's a big argument either way here, but I'm curious about your mentioning C++20, I thought C++ already had float atomics (with bitwise equality for cmpxchg, notably). Does the new proposal do something special with floats? And if so, should we wait for that to stabilize before we try to guess what we might need to support it?

I think not having float atomics in wasm at this point gains us mostly time to assess needs, and time to focus on other things that are more critical.

[jfbastien]

As you say, I don't think there's a big argument either way here, but I'm curious about your mentioning C++20, I thought C++ already had float atomics (with bitwise equality for cmpxchg, notably). Does the new proposal do something special with floats? And if so, should we wait for that to stabilize before we try to guess what we might need to support it?

http://wg21.link/P0020

I think not having float atomics in wasm at this point gains us mostly time to assess needs, and time to focus on other things that are more critical.

Agreed it's not critical, and the cost of adding it later is very low. At worst we have bitwise coercions for a while.

[binji]

We agreed in the CG meeting to the following (for v1 threads):

• No to float atomics
• Yes to i64 atomics (not including wait)

There was not a strong agreement for or against i64.wait.