tc39 / proposal-ecmascript-sharedmem

Shared memory and atomics for ECMAscript
Mozilla Public License 2.0
375 stars 32 forks source link

More uncommon ISAs? #140

Closed juj closed 8 years ago

juj commented 8 years ago

How does the spec look from the perspective of implementing on the more exotic systems that are still relevant today? Thinking about SPARC and PowerPC mostly. Our atomic primitive is a full barrier, and only aligned up to 4-byte atomic accesses are provided, so it feels like a very generic requirement for any particular arch that everything should be good there. Any known special cases on this front?

lars-t-hansen commented 8 years ago

SPARC and POWER (and MIPS) should be well within the envelope of what I've designed for.

See MACHINES.md for more information. IIRC I've not discussed SPARC there but from what I've seen we should be fine (SPARC-TSO is like x86 and SPARC-RMO is like ARM/POWER).

There may well be more exotic architectures out there but in practice my feeling has been that all hardware that will run ECMAScript will have to run C++ and Java too, and they have much more challenging requirements than this proposal. Notably C++ requires (indeed defaults to) sequentially consistent atomics so our requirement for that should not be a problem; Java requires some races (on pointer values) to be predictable, so again our requirement to make races somewhat defined should be OK.

One could envision an architecture that allows Java's data races but not ECMAScript's since ES has aliased arrays and a program can have a race that involves accesses of different sizes, which won't happen in Java, but such an architecture would not be mainstream. Furthermore, given some of the practical problems with C and C++ (where it is essentially necessary to allow memory that was not initialized with atomic instructions to be accessed by atomics) I doubt we'll run into such a machine.

juj commented 8 years ago

Thanks, very informative!

jfbastien commented 8 years ago

Alpha would be the architecture which suffers the most, and C++ has already taken a memory model which makes it perform poorly. I entirely agree with Lars :smile: