Regarding return values: consider f(g()), where would you store the return value of g() ?
If you compile a normal c code with local primitive variables, you would probably see that most local variables are NOT stored in the HEAP. In your previous example you were using structures, but normally local variables are mostly integers or pointers. E.g. ``` int s = 0; for(int i = 0; i < 100; ++i) s += i; ``` I remember that putting local variables to HEAP is slower than in registers, also it is costly to iterating all the local variables, and I do want to avoid that if possible, but I don't want it affect the performance of the sync cases. regards, - Lu On Mon, Jul 28, 2014 at 5:43 PM, Soeren Balko <[email protected]> wrote: > I am not entirely sure why you would need to save return values, as > producing that value and exiting from the function happens concurrently, > i.e., there is no room for an asynchronous break-out to > emscripten_sleep(...) in between, no? > > But regardless of all that - I think that instead of creating local > variables in the resulting Javascript function, you *could* as well place > all local variables in a continuous region in the asm.js HEAP array (as it > already happens to any variables, which cannot be represented as an > asm.js-compliant Javascript variable). Once all local variables are > represented in this manner, saving them is as simple as remembering the > current value of STACKTOP. The offset of the variables on the stack (HEAP > array) is static information that is fixed at compile time (essentially, > offsets from the current stack frame), i.e., no extra runtime effort is > needed when restoring the local variables. > > But anyhow: that's an optimization only - perhaps saving all the variables > by iteratively copying their values somewhere isn't all that costly. > > Soeren > > > On Monday, July 28, 2014 1:55:36 PM UTC+10, 王璐 wrote: > >> That's not completely correct, some are not stored in the heap/stack, for >> example, return values of functions called, or phi nodes. >> >> >> On Sun, Jul 27, 2014 at 8:53 PM, Sören Balko <[email protected]> wrote: >> >>> At compile time: there were no reall local variables any more, >>> everything was in the HEAP array, starting at the address represented by >>> STACKTOP. A function scope was no real JS object but merely a continuous >>> range of bytes in the HEAP array. >>> >>> Am 28 Jul 2014 um 1:44 pm schrieb Lu Wang <[email protected]>: >>> >>> How could you create the scope object with all the necessary local >>> variables, without traversing all of them? >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "emscripten-discuss" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>> topic/emscripten-discuss/kSMH2N0CoLg/unsubscribe. >>> To unsubscribe from this group and all its topics, 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 a topic in the >>> Google Groups "emscripten-discuss" group. >>> To unsubscribe from this topic, visit https://groups.google.com/d/ >>> topic/emscripten-discuss/kSMH2N0CoLg/unsubscribe. >>> To unsubscribe from this group and all its topics, 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 a topic in the > Google Groups "emscripten-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/emscripten-discuss/kSMH2N0CoLg/unsubscribe > . > To unsubscribe from this group and all its topics, 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]. For more options, visit https://groups.google.com/d/optout.
