perpare for more compact bit operations in JS

[ringabout]

Before: it is hard to reuse same variables by emitting JS(see #16609)

when defined(js):
  proc toBitsImpl(x: float): array[2, uint32] =
    asm """
    const buffer = new ArrayBuffer(8);
    const a = new Float64Array(buffer);
    const b = new Uint32Array(buffer);
    a[0] = `x`;
    `result` = b
    """

  proc jsSetSign(x: float, sgn: bool): float =
    asm """
    function updateBit(num, bitPos, bitVal) {
      return (num & ~(1 << bitPos)) | (bitVal << bitPos);
    }
    const buffer = new ArrayBuffer(8);
    const a = new Float64Array(buffer);
    const b = new Uint32Array(buffer);
    a[0] = `x`;
    b[1] = updateBit(b[1], 31, `sgn`);
    `result` = a[0]
    """

After
You could reuse these variables in a proc.

   const buffer = new ArrayBuffer(8);
   const a = new Float64Array(buffer);
   const b = new Uint32Array(buffer);

[timotheecour]

see also: #14128 which is relevant. The fact that your PR lives in std/private is good, it means we can keep improving the API until it stabilizes

[timotheecour]

should this be arr: Float64Array or arr: var Float64Array ? I'm really not sure here since the type is ref, but really, Float64Array + friends act like seq, so var seems to make more sense here.

what are downsides of using var here?

[ringabout]

var will generates array of typed array

[timotheecour]

yes, this is generally true of var in nim js; the question is whether this has a performance impact in this case or whether v8 can optimize this (I'm not sure how to check other than performance timing)

[ringabout]

It seems to cause some errors in some situations, but I forgot the example.

[timotheecour]

note that for var you need the awkard syntax like this: [#][0][0]

# eg: jsbigints:
func inc*(this: var JsBigInt; amount: JsBigInt) {.importjs: "([#][0][0] += #)".} =

(until nim-lang/RFCs#315 is resolved)