Closed juj closed 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.
Thanks, very informative!
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:
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?