Wasm global and local variables, common confusions and possible solutions

[ionic solar]

Hi all,

I'm working on Wasm and its security, mainly tinkering with compilers and programming languages that can compile to Wasm. When I have to explain Wasm and its concepts to a fellow developer, most of the time they struggle to understand the notion of "Wasm local and global variables" and the fact that they are not global or local variables as present in most programming languages. Once they understand, they still assume that Wasm locals and globals are linked in some way to local and global variables in programming language (like supposing that there is a mapping made between programming language global and local variables and Wasm globals and locals that is done at compile time, so that Wasm globals and locals have a direct counterpart in their language. Another common mistake I hear is saying that Wasm local and global variables can only hold "variables" of a programming language, which is of course untrue (e.g. LLVM use a global variable as a "register" to store the stack pointer). These mistakes are exacerbated when communicating by writing, and using not interactive means (like a blog post or an article).

This led me to think that I must not be the only one in the Wasm community to have this kind of trouble, and I'm coming here to look for good answers to these problems. Frankly, I'm even thinking that the terms "Wasm global and local variables" were poorly chosen and could maybe be changed. I'm hoping this topic is of interest not only for me be also for a sizable amount of Wasm users. I have a list of questions to propose, and I'm happily taking any feedback one may give.

• Do you already had trouble / confusion when explaining Wasm local and global variables ?
• How do you proceed to explain these clearly and avoid the confusion ?
• Did you already think that the "global and local variables" terms were poorly chosen ?
• If yes, do you think these terms should be changed ? Do you have ideas ?

Thanks for all your answers, and happing Wasming !

[steep wigeon]

i'm confused

in my mind they map fairly reasonably to local and global variables in traditional languages?

what are the major differences you're talking about when explaining the concept

[ionic solar]

First of all, the Wasm variables are restricted to Wasm basic types, so cannot hold the more complex types of traditional languages

Then, the mapping between simple programming languages variables and Wasm variables is possible, but not enforced by the spec / the compiler can choose not to do that for whatever reason

[steep wigeon]

wouldn't it be better then to say that the language of webassembly only has x built in types and doesn't allow you to define any custom types
they're still your regular old variables

[stable quartz]

In AssemblyScript, they actually map almost 1:1 to global and local variables in the language

C, on the other hand, has stack allocations and such

[stable quartz]

Wasm is pretty low-level

ELF doesn't know what a struct is, or what an array is (correct me if I'm wrong)

[ionic solar]

Maybe but you lose all the power of complex programming languages, and the possibility to port old programs to Wasm

[steep wigeon]

wdym possibility to port old programs to wasm?

you aren't losing anything

[ionic solar]

Yeah but AssemblyScript was designed specifically with Wasm in mind, so not surprising... This is not the case in general

[stable quartz]

Yup, I believe most cases are closer to C's

[stable quartz]

Noooooo you don't.

Wasm isn't supposed to be a perfect mapping of every programming language or anything

Wasm is a compilation target

[ionic solar]

Like compiling programs that were written before Wasm to a Wasm binary (my main use case is Wasm/WASI, but some programs can be compiled to Wasm in the browser)

[stable quartz]

That's what the WASI SDK and Emscripten are for

[steep wigeon]

what would block you from doing that?

[stable quartz]

The former is tailored towards servers, and the latter is tailored towards browsers

[ionic solar]

Well nothing, I'm just saying that the "variable" term in Wasm is confusing to work with and explain when you want to work with Wasm and traditional programming languages, as they are not really correlated

[steep wigeon]

i think you're looking at wasm too much as something you'd write manually and less of a compilation target

wasm variables are traditional variables, but all rules are tossed out the window when you're compiling

[stable quartz]

^^^

[stable quartz]

^^^

[steep wigeon]

maybe 5 of the variables in your C function use the same local because they're used at distinct points in the function

or a few are inlined and aren't represented in any local at all

[stable quartz]

If you disassemble an Arm binary, you'll find that it doesn't look very similar to your source at all

What csjh said about reusing locals would apply here too

[ionic solar]

Okay, I see you point. But then, if Wasm is a compilation target, why use the "variable" term instead of "registers" or another term that is closer to compilation targets and not similar to one used in programming languages?

[stable quartz]

I'm not entirely sure, but too late

My guess is that registers are finite, but you can have as many local variables as you want (well, there's a limit, but whatever)

The maximum number of locals declared in a function, including implicitly declared as parameters, is 50,000.
for JS embeddings

[stable quartz]

@ionic solar also Wasm is stack-based, not register-based, so naming them registers probably invites confusion of its own

[ionic solar]

Indeed

[steep wigeon]

if they named them registers i would question why they aren't called variables tbh