> 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 On Fri, Jun 30, 2023 at 8:39 AM 'Sam Clegg' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > 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 > > On Thu, Jun 29, 2023 at 1:20 PM Mark Sibly <marksi...@gmail.com> wrote: > >> 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 >> >> >> >> On Wed, Jun 28, 2023 at 3:19 PM Mark Sibly <marksi...@gmail.com> wrote: >> >>> 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 >>> >>> -- >>> 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-discuss+unsubscr...@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 >>> <https://groups.google.com/d/msgid/emscripten-discuss/4062abb6-e1cb-44b3-887a-333ceb8ed808n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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. >> 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 >> <https://groups.google.com/d/msgid/emscripten-discuss/CAK32ozg_E2hR_ZJsSQBHZ%3Dh5yidabQgkybBjc68Y2K-S5%3DooXQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_8NyWd60F42CKqMD%3Djur0GmZtGwHWcVvvjAhqV0qwGJw%40mail.gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2_8NyWd60F42CKqMD%3Djur0GmZtGwHWcVvvjAhqV0qwGJw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAK32oziZUn71VdbCimVedJyxFJggRm5DULRDT1Mz%2BHSfZRak0A%40mail.gmail.com.
