CODE AND STORAGE OVERLAP while building firmware for NRF52

Thats just first step to move it out of static array. And worth it even alone since the variable size is just a guesswork now (?) and also depends on size of globals, i.e you add some globals over time (or only with some specific build options - like e.g. some display driver with some buffer) and need to think to shrink variables. With this they are sized automatically to fill all available space.

The only guesswork that remains is stack, which can be checked/tuned by stack painting and monitoring its size. Is there some stack check now at runtime or it will silently overwrite variables now (and other random globals a bit earlier since in lst file jsVars array is somewhere between globals)? If you don't set stack size explicitly now at build time and compensate for it by shrinking variables by trial and error, that's not ideal.

As for resizing I agree this is not priority because of MTU allocation and is definitely separate step. In fact it would make more sense for stability and safety first - on stack side. It could try to e.g. shrink variables when stack grows over some safe threshold instead of crashing or corrupting data.

Overall agree changing size at runtime is not trivial however this first step (= optimal static allocation outside of static variable array declaration) is easy and removes some uncertainty and guesswork.

As for dynamic heap, that's between __HeapStart,__HeapLimit now and is zero (so default malloc should fail?). As for that long writes code using malloc I linked, I don't know why or if that worked, maybe the guy increased heap at build time with -D__HEAP_SIZE=, that would work for him and would work also with this patch (and shrink variables automatically).

Was just asking to know if it makes sense to clean it up a bit and send PR for this. However it needs some first default stack size guess (possibly for each SDK,platform) - fortunately this feature can be gradually enabled per board.

BTW, already found one bug/feature related to this - process.memory().stackEndAddress returns LINKER_END_VAR instead of __StackLimit which is the real end of stack. And with this patch without fix it currently points to beginning of variables, not end. So the fix is to change it to __StackLimit.

However from the comments https://github.com/espruino/Espruino/blo­b/master/src/jswrap_process.c#L139 it looks like it is on purpose even if it really means end of globals and not end of stack. Not sure what was the reason to provide this feature exactly - some form of small and dangerous dynamic heap?