Emscripten exe data size?

[Mark Sibly]

Hi,

I'm writing a simple wasm compiler for a version of BASIC, and am planning to link the output with an emscripten coded 'runtime' wasm module.

I tried to do this once before by adding support for the custom lld sections earlier, but it turned into a bit of an ordeal (it was over half the code!) so I gave up. The new plan is to link with an emscripten runtime at the 'final module' level.This involves loading the emscripten runtime wasm module, and than appending my compiler output to this to create a new standalone module. The main idea here is that I wont have to mess with the emscripten stuff much - I can just add my functions to the end of the functions table etc.

The first problem I've encountered though is how to append static/global data. My code will need to use memory offsets past the end of whatever the emscripten runtime needs (and before dynamic memory which I guess comes from the same pool?) and the only way I can think of to do this is to add pages to the 'memory' import, but the resolution of that would be 64K which isn't bad I guess but seems excessive.

Is there any way to be able to tell from looking at a wasm module what the 'highest' memory address it uses is? I remember C used to have data_start and data_end (or similar) globals and was hoping emscripten might export something similar but it doesn't seem to.

Bye!

Mark

[Mark Sibly]

Ok, as far as I can work out emscripten runtime memory (ie: 'memory 0') is laid out like this: App fixed sized static data (ie: BSS/DATA) -> Emscripten Stack (not wasm control flow stack) -> Heap memory. Is this correct?

Top of stack/start of heap memory is defined by the globals __stack_pointer and __heap_base, so if I want to add my own fixed size static data I should start at offset __stack_pointer - STACK_SIZE, and increase the globals __heap_base and __stack_pointer by the size of my own static data.

Should this work? Is there any way to determine STACK_SIZE directly from the wasm module?

Bye!

Mark

--
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/Esy2xhLbEFg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/4062abb6-e1cb-44b3-887a-333ceb8ed808n%40googlegroups.com.

[Sam Clegg]

If you want a static region of memory that you can use for your own purposes, one way to achieve that would be to build with `-sGLOBAL_BASE=10mb` .. that will offset the emscripten stack and heap leaving you the first 10mb of memory to do with what you will.

BTW, you might want to check out the wasm-merge tool which is part of binaryen if you want to merge the emscripten output with your compiler output.   Alternatively you could leave them unmerged and load your compiled code as a separate module at runtime.  Both ways should work.  One advantage of the runtime method is that you could have a single emscirpten output that would be able run any/all of your compiled modules without needing to re-run emscripten.   You could also then allocate the memory needed for your compiled module using `malloc` and pass in the data ranges.  Users of your compiler then wouldn't even need to have emscripten installed in order to run their compiled BASIC modules.

cheers,

sam

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-disc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAK32ozg_E2hR_ZJsSQBHZ%3Dh5yidabQgkybBjc68Y2K-S5%3DooXQ%40mail.gmail.com.

[Mark Sibly]

> one way to achieve that would be to build with `-sGLOBAL_BASE=10mb`

I didn't know about that and it sounds like it would definitely do the trick, although I would have to use a worse case global base if I want to avoid having to rebuild the runtime all the time.

> BTW, you might want to check out the wasm-merge tool which is part of binaryen if you want to merge the emscripten output with your compiler output.

Wasm-merge also looks interesting, but I don't understand how it can relocate static data addresses. These are just i32.const values in wasm, so wont it fail if you try to merge 2 modules that use the same 'global base' for different data? Or is there a way to do this with PIC or something?

> Alternatively you could leave them unmerged and load your compiled code as a separate module at runtime

Being able to load the runtime as a 'dll' at runtime would be kind of ideal, but I thought wasm couldn't do this without the use of a javascript 'bridge' or something, or has this changed? Since I want the runtime to provide low level language stuff, I wouldn't be happy with this additional overhead.

Thanks for the very useful hints!

Bye,

mark

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_8NyWd60F42CKqMD%3Djur0GmZtGwHWcVvvjAhqV0qwGJw%40mail.gmail.com.