We are directly compiling to wasm. Our code also generates a data structure with fields (scalar and arrays). A solution we may use for now is to move those stack allocated data in the structure, since I understand that in any case the data finally live in a wasm memory region (this this should not cause any performances changes yes ?). But having support in binaryen could be interesting, although it somewhat link the generated wasm model to binaryen API, something we may ant to avoid in case the generated module is deployed in another context.
Le lundi 14 août 2017 18:42:40 UTC+2, Alon Zakai a écrit : > > What emscripten would do is set aside a range of memory for the stack, and > maintain a stack pointer. Then "foo" would be assigned a region at the top > of the stack on entry to that function, and the stack would be unwound when > the function is exited. > > Are you compiling directly to wasm yourself? Or to LLVM bitcode? If > bitcode then you can easily reuse the emscripten runtime to do a lot of > this for you. Otherwise you may need to do more yourself, but perhaps we > should find ways to make that easier (e.g., maybe in binaryen's APIs for > generating wasm we could add stack support). > > > On Mon, Aug 14, 2017 at 8:16 AM, <[email protected] <javascript:>> wrote: > >> OK. Then how the equivalent C code should be generated then ? Where is "foo" >> array memory supposed to be allocated ? >> >> void test() >> { >> float foo[36]; >> float* foo_ptr = &foo[4]; >> ... >> code that uses foo_ptr >> ... >> } >> >> Thanks. >> >> Le lundi 14 août 2017 17:07:38 UTC+2, jj a écrit : >>> >>> Stack is optional. If you are targeting Wasm directly, you do not need >>> to have a stack at all if your language domain does not need it. What >>> Emscripten does with the stack is it blocks out a linear chunk of >>> memory at startup and calls that the stack, and whenever compiled code >>> does things like takes the address of a local variable, it must be >>> pushed to the WebAssembly Memory out from a Wasm function local, so >>> that it can be referenced by a pointer in other functions. WebAssembly >>> itself does not care about Emscripten's STACKTOP etc., but all it >>> operates on are the get_local and set_local type of opcodes for >>> function local data. >>> >>> 2017-08-14 17:18 GMT+03:00 <[email protected]>: >>> > Hi, >>> > >>> > We are compiling to wasm code from our Faust DSP compiler (so >>> producing our >>> > own wasm modules). >>> > >>> > In our wasm code, it is not clear yet how we could possibly define >>> stack >>> > allocated arrays. Compiling a C++ code example, I see that Emscripten >>> > runtime code has some stack operations (like >>> > stackSave/stackAlloc/stackRestore...) and generates stack related code >>> in >>> > the function header. So I understand that Emscripten runtime allocates >>> a >>> > block of memory to be used for the stack yes?, but what to do in if we >>> don't >>> > interact with the Emscripten runtime? Do we need to manage our own >>> stack in >>> > a similar way as Emscripten runtime does? Or are they any simpler >>> > recommended way? >>> > >>> > Thanks. >>> > >>> > Stéphane Letz >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "emscripten-discuss" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to [email protected]. >>> > For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
