Re: Local stack allocated arrays, and stack management in WebAssembly code

[Alon Zakai]

You can look at the wasm generated for that function (using wasm-dis in
binaryen or wasm2wast in wabt, etc.).

If you also want to look at LLVM IR, you don't need to wait for the wasm
backend. Are you compiling with emscripten? Then just tell it to emit
bitcode, -o name.bc instead of js or html. If not with emscripten, but you
are using clang, then you can tell it -emit-llvm.

On Wed, Aug 23, 2017 at 8:10 PM,  wrote:

> OK.
>
> "Looking at the generated IR code can confirm" ==> do you mean : LLVM IR
> yes ? I don't really understand how I can check the IR code then... Maybe
> we have to wait for the LLVM wasm backend to be ready, and compare the LLVM
> IR ==> wasm step (and speed of resulting code) with the speed of the code
> generated by our own direct Faust wasm backend?
>
> Le mercredi 23 août 2017 20:53:23 UTC+1, Alon Zakai a écrit :
>>
>> It might be cache locality. Otherwise there is nothing magical about the
>> stack in both native code and wasm, it's just another region of memory,
>> reading and writing from it is the same as reading or writing anywhere else
>> (again, minus locality issues - which might be different in wasm).
>>
>> If not cache locality, it could be that the C++ compiler's optimizer
>> happens to do better on your stack version. Looking at the generated IR
>> code can confirm. This seems more likely to me.
>>
>>
>> On Wed, Aug 23, 2017 at 11:22 AM,  wrote:
>>
>>> Refining the question then (I'm discussion here at the Web Audio
>>> Conference with Paul Adenot working on WebAudio at Mozilla...).
>>>
>>> It appears that when compiling from Faust to a C++ class, having those
>>> arrays allocated on the stack (when we can afford it because they contain a
>>> state that does not live outside of the function scope), the code is faster
>>> compared to when we move those arrays as class fields. With Paul we were
>>> exploring reasons for that: better cache locality ? faster access of data
>>> allocated on the stack compared to the same data in the class field so
>>> allocated in the heap?
>>>
>>> Anyway: since in WebAssembly the stack is basically a part of the wasm
>>> module memory block, then is seems that we'll never be able to achieve this
>>> kind of "when compiled in C++, local stack data is faster to access than
>>> the same data on the heap..." property. Or is this part of the wasm
>>> compilation step strategy ?
>>>
>>> Paul told me that Luke Wagner of Benjamin Bouvier at Mozilla could
>>> possibly answer this kind of "wasm compilation strategy" questions. Do they
>>> read this group?
>>>
>>> Thanks.
>>>
>>>
>>> Le mardi 15 août 2017 16:50:28 UTC+1, Alon Zakai a écrit :

 Yes, in the end all the data has to live in the wasm memory (or in wasm
 globals). So it's basically up to you how to use that memory, which is sort
 of like defining your own ABI, if you choose not to use an existing one.

 On Tue, Aug 15, 2017 at 12:43 AM,  wrote:

> 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,  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 = [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 

Re: Local stack allocated arrays, and stack management in WebAssembly code

[Alon Zakai]

It might be cache locality. Otherwise there is nothing magical about the
stack in both native code and wasm, it's just another region of memory,
reading and writing from it is the same as reading or writing anywhere else
(again, minus locality issues - which might be different in wasm).

If not cache locality, it could be that the C++ compiler's optimizer
happens to do better on your stack version. Looking at the generated IR
code can confirm. This seems more likely to me.


On Wed, Aug 23, 2017 at 11:22 AM,  wrote:

> Refining the question then (I'm discussion here at the Web Audio
> Conference with Paul Adenot working on WebAudio at Mozilla...).
>
> It appears that when compiling from Faust to a C++ class, having those
> arrays allocated on the stack (when we can afford it because they contain a
> state that does not live outside of the function scope), the code is faster
> compared to when we move those arrays as class fields. With Paul we were
> exploring reasons for that: better cache locality ? faster access of data
> allocated on the stack compared to the same data in the class field so
> allocated in the heap?
>
> Anyway: since in WebAssembly the stack is basically a part of the wasm
> module memory block, then is seems that we'll never be able to achieve this
> kind of "when compiled in C++, local stack data is faster to access than
> the same data on the heap..." property. Or is this part of the wasm
> compilation step strategy ?
>
> Paul told me that Luke Wagner of Benjamin Bouvier at Mozilla could
> possibly answer this kind of "wasm compilation strategy" questions. Do they
> read this group?
>
> Thanks.
>
>
> Le mardi 15 août 2017 16:50:28 UTC+1, Alon Zakai a écrit :
>>
>> Yes, in the end all the data has to live in the wasm memory (or in wasm
>> globals). So it's basically up to you how to use that memory, which is sort
>> of like defining your own ABI, if you choose not to use an existing one.
>>
>> On Tue, Aug 15, 2017 at 12:43 AM,  wrote:
>>
>>> 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,  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 = [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  :
>> > 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 

Re: Local stack allocated arrays, and stack management in WebAssembly code

[letz]

Refining the question then (I'm discussion here at the Web Audio Conference 
with Paul Adenot working on WebAudio at Mozilla...). 

It appears that when compiling from Faust to a C++ class, having those 
arrays allocated on the stack (when we can afford it because they contain a 
state that does not live outside of the function scope), the code is faster 
compared to when we move those arrays as class fields. With Paul we were 
exploring reasons for that: better cache locality ? faster access of data 
allocated on the stack compared to the same data in the class field so 
allocated in the heap?  

Anyway: since in WebAssembly the stack is basically a part of the wasm 
module memory block, then is seems that we'll never be able to achieve this 
kind of "when compiled in C++, local stack data is faster to access than 
the same data on the heap..." property. Or is this part of the wasm 
compilation step strategy ?  

Paul told me that Luke Wagner of Benjamin Bouvier at Mozilla could possibly 
answer this kind of "wasm compilation strategy" questions. Do they read 
this group?

Thanks.


Le mardi 15 août 2017 16:50:28 UTC+1, Alon Zakai a écrit :
>
> Yes, in the end all the data has to live in the wasm memory (or in wasm 
> globals). So it's basically up to you how to use that memory, which is sort 
> of like defining your own ABI, if you choose not to use an existing one.
>
> On Tue, Aug 15, 2017 at 12:43 AM,  wrote:
>
>> 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,  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 = [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  : 
> > 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. 
> 

Re: Local stack allocated arrays, and stack management in WebAssembly code

[Alon Zakai]

Yes, in the end all the data has to live in the wasm memory (or in wasm
globals). So it's basically up to you how to use that memory, which is sort
of like defining your own ABI, if you choose not to use an existing one.

On Tue, Aug 15, 2017 at 12:43 AM,  wrote:

> 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,  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 = [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  :
 > 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 emscripten-discuss+unsubscr...@googlegroups.com.
 > 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 emscripten-discuss+unsubscr...@googlegroups.com.
>>> 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 emscripten-discuss+unsubscr...@googlegroups.com.
> 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 emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Local stack allocated arrays, and stack management in WebAssembly code

[letz]

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,  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 = [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  : 
>>> > 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 emscripten-discuss+unsubscr...@googlegroups.com. 
>>> > 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 emscripten-discuss+unsubscr...@googlegroups.com .
>> 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 emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Local stack allocated arrays, and stack management in WebAssembly code

[Alon Zakai]

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,  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 = [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  :
>> > 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 emscripten-discuss+unsubscr...@googlegroups.com.
>> > 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 emscripten-discuss+unsubscr...@googlegroups.com.
> 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 emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Local stack allocated arrays, and stack management in WebAssembly code

[letz]

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 = [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  : 
> > 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 emscripten-discuss+unsubscr...@googlegroups.com . 
> > 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 emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Local stack allocated arrays, and stack management in WebAssembly code

[Jukka Jylänki]

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  :
> 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 emscripten-discuss+unsubscr...@googlegroups.com.
> 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 emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Local stack allocated arrays, and stack management in WebAssembly code

[letz]

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 emscripten-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.