feat: 64-bit system API

[mraszyk]

This PR introduces system API functions taking 64-bit WASM memory addresses.

[github-actions[bot]]

🤖 Here's your preview: https://if4il-kaaaa-aaaak-qcnfa-cai.icp0.io/docs

[luc-blaeser]

Thanks a lot Martin for this PR. Very nice. As mentioned by Claudio, the only question I have is related to overloading whether this could cause any difficulties with Rust or other non-overloading-capable languages. A kind of a generic API with a parametric main memory pointer type determined based on the bit-width of the main memory seems like an interesting solution approach, provided that it can be easily realized in the IC implementation.

[alexandru-uta]

I see that for many function calls only dst has type I, but where it semantically makes sense, should we also have offset and size also type I?

[mraszyk]

I see that for many function calls only dst has type I, but where it semantically makes sense, should we also have offset and size also type I?

Do you foresee that canisters will be dealing with more than 4GB of data in one system API call? In that case, using I everywhere would be necessary.

[alexandru-uta]

I see that for many function calls only dst has type I, but where it semantically makes sense, should we also have offset and size also type I?

Do you foresee that canisters will be dealing with more than 4GB of data in one system API call? In that case, using I everywhere would be necessary.

Not necessarily, but on the implementation side it's usually much more cleaner to have all args the same type. @eust-dfinity and @luc-blaeser, what's you take on this?

[ghost]

I see that for many function calls only dst has type I, but where it semantically makes sense, should we also have offset and size also type I?

Do you foresee that canisters will be dealing with more than 4GB of data in one system API call? In that case, using I everywhere would be necessary.

Not necessarily, but on the implementation side it's usually much more cleaner to have all args the same type. @eust-dfinity and @luc-blaeser, what's you take on this?

Most probably we won't need offsets and sizes bigger than 32bit. However it makes sense from the api perspective to have them of the same type. It is more convenient to call copy(src/dst, buf, buf.size()) without having to cast buf.size() to a smaller type. All the other 64bit functions involved have consistent u64 arguments (e.g. our stable64 api have offsets and lengths as u64 even though it used to copy to a 32bit destination).

I guess the question is what is more expected (unexpected) from a typical developer perspective. (for me the more expected is 64bit everywhere)

[luc-blaeser]

I guess the question is what is more expected (unexpected) from a typical developer perspective. (for me the more expected is 64bit everywhere)

I agree, it would somewhat ease the integration as it is uniform with the address bit-width and probably save some casts (by the CDK and maybe also in the IC runtime).

[crusso]

I just double-checked with @luc-blaeser and he is fine (and already assumes) 32-bit env values for any callbacks.