Update type definitions for memory.* intrinsics

[jayphelps]

I think that #592 removed these intrinsics and added the ones that are currently available. __alloc is technically available, but not included in the type definition. I assume that's expected and not intended as a "public" stable API, similar to how __heap_base etc aren't included in the type def either.

[jayphelps]

I see the full test suite is failing. Interesting. Looks like some tests rely on these, but it's not clear how that can be as they weren't available to me. Maybe I'm mistaken about them no longer being exposed, and my local build is just screwed up.

I'll dig, but lmk if you already know the answer easily.

[dcodeIO]

There are two distinct definition files, one for compiling to Wasm with asc (that has all the Wasm features we support) and one for cross-compiling to JS with tsc (the one mistakenly? updated in this PR). The portable definitions appear to be somewhat outdated, but it is correct that these can't provide the full set of instructions, like there's no memory.grow unless we explicitly implement a portable polyfill here. There is some information on the portable variant on the docs, but ultimately this hasn't been fleshed out in perfect detail yet because it keeps evolving based on the compiler's needs, which it itself portable. Should definitely update the portable memory definitions, though, as there's no memory.allocate etc. anymore and these defs are wrong now.

[jayphelps]

That makes more sense! However, it turns out memory.allocate/free are still used by the compiler itself which puzzles me. I found the implementation code for them in the portable runtime, but not in the assembly one which makes me confused how asc can run if compiled to Wasm? I'm still familiarizing myself with the codebase, forgive me.

If my understanding is correct (probably isn't?) it seems like memory.allocate/free are implemented for when you're compiling to JS but not for when you're compiling to Wasm, which means we'd need to either re-implement them for Wasm or remove them from portable and move the compiler internals to use the managed GC.

FWIW I think it's useful to publicly support exposing a raw bytes alloc function in some form, e.g. __alloc the one used by the GC runtime. But that doesn't have to be now. I need this, for example, but I can do my own thing for now. Someone could use AS's TypedArrays similarly, but not the same as it comes with some baggage.

[dcodeIO]

However, it turns out memory.allocate/free are still used by the compiler itself which puzzles me.

That's correct, but the implementation there doesn't have much in common with actual Wasm memory. This is rather a hacky shim originating from the necessity to somehow access Binaryen's memory, for example when creating C-strings for it to use. See also this PR that removes the portable memory stuff completely (figured that this is more confusing than it should be) and instead calls Binaryen's exported _malloc and _free directly instead of hiding it behind another API in ambiguous ways.

but not in the assembly one which makes me confused how asc can run if compiled to Wasm?

Plan is that the compiler itself does not need Wasm-specific instructions at all, but instead relies exclusively on the runtime to do the heavy lifting. Like, the portable subset it is written in can be imagined as the intersection of functionality that is available in both TS and Wasm. Note that the compiler does not yet compile to Wasm due to some remaining missing features.

or remove them from portable and move the compiler internals to use the managed GC.

That's exactly the plan, yeah.

FWIW I think it's useful to publicly support exposing a raw bytes alloc function in some form

Would recommend the following to do this, resorting to unsafe code:

function malloc(size: usize): usize {
  return __retain(changetype<usize>(new ArrayBuffer(<i32>size)));
}
function free(ptr: usize): void {
  __release(ptr);
}

Doesn't necessarily have to be these exact functions, but this way one essentially gets a managed ArrayBuffer that is interoperable with anything C-like.

[jayphelps]

Thanks for clarifying! Sounds like this PR is superseded by #971 so will close 🕺