compiler-internals: remove -wasm-abi=generic flag

Also update the text a bit.

Author: aykevl

content/docs/concepts/compiler-internals/calling-convention.md

@@ -18,11 +18,11 @@ TinyGo, however, uses a register based calling convention. In fact it is somewha
 
     Note that all native Go data types that are lowered to aggregate types in LLVM are expanded this way: `string`, slices, interfaces, and fat function pointers. This avoids some overhead in the C calling convention and makes the work of the LLVM optimizers easier.
 
-  * The WebAssembly target by default doesn't export or import `i64` (`int64`, `uint64`) parameters. Instead, it replaces them with `i64*`, allocating the value on the stack. In other words, imported functions are called with a 64-bit integer on the stack and exported functions must be called with a pointer to a 64-bit integer somewhere in linear memory.
+  * Some environments don't support `i64` parameters and return values (like old Node.js versions). Therefore, when targeting browsers, TinyGo will use a special ABI where these parameters and return values are returned with `i64`, allocating the value on the C stack. In other words, imported functions are called with a 64-bit integer on the stack and exported functions must be called with a pointer to a 64-bit integer somewhere in linear memory.
 
-    This is a workaround for a limitation in JavaScript, which only deals with doubles and can therefore only work with integers up to 32-bit in size (a 64-bit integer cannot be represented exactly in a double, a 32-bit integer can). It is expected that 64-bit integers will be [added in the near future] (https://github.com/WebAssembly/design/issues/1172) at which point this calling convention workaround may be removed. Also see [this wasm-bindgen issue](https://github.com/rustwasm/wasm-bindgen/issues/35).
+    WASI doesn't have this limitation so it will always use plain `i64` values.
 
-    Currently there are also non-browser WebAssembly execution environments that do not have this limitation. Use the -wasm-abi=generic flag to remove the behavior described above and enable emitting functions with i64 parameters directly.
+    We will eventually remove support for this workaround, as it is only really needed for very old Node.js versions.
 
   * The WebAssembly target does not return variables directly that cannot be handled by JavaScript (see above about `i64`, also `struct`, `i64`, multiple return values, etc). Instead, they are stored into a pointer passed as the first parameter by the caller.