That was actually a very easy part of EXODUS. Since TempleOS is basically a unikernel, it doesn't need any code for per-process virtual address space.

So I can just map some pages in the host process and the host process' address space becomes the HolyC kernel's entire address space, which is ironic since Terry was always adamant about how he disliked modern isolated per-process address spaces and that turned out to be a key to porting his OS to Ring 3.

I did need some code for "code pages" though - since all function calls in TempleOS use the 32 bit relative call instruction, all compiled HolyC code go in the lower 32 bit address space. Some Linux distros like to map the ELF binary at that address range too, so I have a routine to read /proc/self/maps and avoid mmapping those areas (I was surprised mmap can overlap without any signs).

Haha, that's like committing blasphemy to achieve a holy goal. I wonder what Terry or God would say about this.

I'm guessing something along the lines of 1 Samuel 13:13 ;-)

https://www.bible.com/bible/114/1SA.13.13

Terry referenced the joke about web browsers, saying that as the most people use internet explorer to download firefox, he used Ubuntu with VMWare to run Temple OS. https://iv.ggtyler.dev/watch?v=IXhmu1aQSOY

Wine has a similar problem around needing to reserve the lower 32 bit address space for 32-bit executables.

I bookmarked their Mac workaround around here: https://github.com/wine-mirror/wine/blob/b2a099b3ceec6fef05c... which involves rearranging the zero page and creating a big WINE_RESERVE section.

On Linux it appears they use a -Ttext linker flag to reposition the code location, but I haven't read it too carefully: https://github.com/wine-mirror/wine/blob/b2a099b3ceec6fef05c...

That's one way to do it, dealing with linkers was really not my thing so I just get the mapped memory list [1] and set it as the start pivot then stack pages on top of it [2]. Thankfully the brk heap isn't intrusive enough to climb up into the pages I allocated :) (this is actually why Linux' MAP_32BIT mmap starts from 0x40000000 [3], but I didn't like how high it was and made it dynamic)

[1]: https://github.com/1fishe2fishe/EXODUS/blob/90f70386b8ac6bd0...

[2]: https://github.com/1fishe2fishe/EXODUS/blob/90f70386b8ac6bd0...

[3]: https://github.com/torvalds/linux/blob/8f2c057754b25075aa3da...

> Thankfully the brk heap isn't intrusive enough to climb up into the pages I allocated :)

That seems about right[1], but the MAP_FIXED_NOREPLACE flag has been a thing since Linux 4.17. What about using that?

[1]: https://godbolt.org/z/698dPcvf6

Thanks for the information, I wasn't aware of that! Seems like it's not available on FreeBSD though ;( I want to support as many OS'es as possible, but I'll still add a comment on that for future reference.

Could it be enabled with a define or other compile-time mechanism for Linux?

Yeah, I could just use that flag on Linux and let the kernel do more work but I'm afraid I might have to add more logic for looping for a failed mmap only for linux, and more ifdefs usually mean I'm doing something wrong. I'd rather roll with my current strategy (finding a safe pivot and keep bumping without checking anything)