Support typed arrays as parameters about validator HOT 4 OPEN

You can copy them in now using typed array .set(). (Also, you likely anyhow do not want to do processing on a clamped array for speed purposes, I think?)

asm.js currently wants to bind tightly to its typed array, for speed purposes, so passing over a new one each call would not fit that model.

from validator.

Not acceptable. Man ctypes, actually useful FFI. Passing in arrays is a mandatory feature.

asm.js currently wants to bind tightly to its typed array, for speed purposes, so passing over a new one each call would not fit that model.

The fuck?!

from validator.

The asm.js model is very simple: a singleton typed array for data storage. This is what makes it super-easy to optimize to native-like speeds.

If the asm spec allowed passing in typed arrays, accessing them would necessary entail the usual type checks, bound checks, bailouts, etc. - meaning it would not run at typical asm.js speed. It could still run pretty fast, because modern JS engines are fast. But it couldn't benefit from the predictable level of performance you can expect from asm.js.

But the important thing is that the singleton typed array in asm.js is not owned by it - it's a normal typed array, accessible from outside the asm module as well. That means you can access other typed arrays in outside code, and that code can also access the asm.js typed array,

var asm = (function asmModule(buffer, stdlib, ffi) {
  "use asm";
  // ...
})(buffer, stdlib, ffi);

function extFunction(newArray) {
  // operations on both buffer and newArray
}

That extFunction can run very quickly. Not typical asm.js speed, but still, if all it does is access some typed arrays and so basic math, that is stuff that modern JS engines can optimize well. And that speed is basically the limit - you couldn't get better from writing that code in asm.

Therefore, there isn't a strong reason to add passing in new arrays to asm code.

from validator.

With non-trivial effort (and thus significant justification required), asm.js modules could have a second heap:

function f(stdlib, ffis, buffer1, buffer2) { "use asm"; ... }

The existing change heap asm.js extension could then be used to arbitrarily swap buffer1 and buffer2. Thus, you could change-heap buffer2 to the result of getImageData() and then pound on this in a subsequent asm.js function call.

I'm not sure how this would be reflected in C++/Emscripten, though. In particular, every heap access would need to statically know which heap to load from and there is no natural way I know of to express this in C++ since the memory model assumes a single linear address space. Some sort of extra annotations would be required (or a bunch of EM_ASM).

from validator.