On 29 Jul 2014, at 11:02, Lu Wang <[email protected]> wrote: > Regarding return values: consider f(g()), where would you store the return > value of g() ?
Not at all - why would I want to store it? My understanding is that somewhere in g, there is a call to emscripten_sleep(). Hence you need to store all local variables of g and f that are declared and initialised before that. The return value of g is only produced after emscripten_sleep() returns - hence no need to store it. Or am I overlooking something. > > 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. Fair point - I do not know if elements of a typed array (which is the representation of the HEAP array), are ever cached in registers. Portions of the array reside in a nearline CPU cache, but - admittedly - not necessarily in registers. Btw, do you also perform some data flow analysis to limit the number of to-be-saved local variables? I mean, you wouldn’t need to save local variables which were *only* used before the emscripten_sleep() call, but not after it. Same is true for local variables that are only used after emscripten_sleep() returns (like in case of the return value). > > > 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 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. Soeren Balko, PhD Founder & Director zfaas Pty Ltd Brisbane, QLD Australia -- 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.
