Not arbitrary JS. Semi-arbitrary machine code. The first few CPUs would restrict it to a couple instructions, with later generations potentially adding instructions.
And as for your second, don't think of it as a standard map. I should have elaborated. Think of it more of a for loop with an index variable and temporary variable per-iteration. You can access (read and write) other things outside of that index too - the only restriction being that the iterations of the loop will execute in an arbitrary order, including simultaneously.
The JS SIMD effort is aimed at finer-grained, hand-written but highly reliable and predictable SIMD as compared to the large-scale, convenient but kinda magic of RiverTrail.
I think you missed the start of my first comment: namely, I was not talking about JS. I was talking about SIMD at the instruction-set level in general.
Adding fuel to your fire: hardware will often be implemented with multiple SIMD compute units (transistors are cheap!), and pipeline multiple SIMD calls. With instruction sets like AVX, the length is increasing.
SIMD is non-controversial: it's just like another ALU instruction but maps the inputs to the outputs differently. Doing something more exotic, like VLIW, is an uphill battle. However, as seen with GPUs, that can be fruitful.
And as for your second, don't think of it as a standard map. I should have elaborated. Think of it more of a for loop with an index variable and temporary variable per-iteration. You can access (read and write) other things outside of that index too - the only restriction being that the iterations of the loop will execute in an arbitrary order, including simultaneously.