[Syllable-kernel] Special handling for >1GB RAM and loading apps at 0x04000000 not 0x80000000?

[Jake H. <jh...@an...>]

After upgrading my laptop to 1.25 GB of RAM (for Windows XP of course, 
not for Syllable!), I have to force Syllable to use a memsize lower than 
1GB in the bootloader or else I get a bunch of fatal areas errors.  I am 
trying to figure out what needs to be done to fix Syllable to work on 
machines with up to 4GB of RAM.  Does anyone know if there is any 
special quirkiness related to Intel-based PC handling of 1GB to 4GB RAM, 
and if so, how to handle it?

One reason I ask is because I recently discovered that Linux's default 
kernel only supports up to 896MB of physical memory.  You need a special 
HIGHMEM enabled kernel to go up to 4GB (or 64GB with 36-bit addressing) 
of RAM.  I've never had that much RAM before so I never noticed.  :-)  I 
guess I will have to grep through the kernel and see what had to be 
changed in Linux to support large memory systems.  I had assumed that it 
would be a simple matter of not accidentally using signed variables for 
pointer arithmetic and taking care to stuff the addresses into the page 
table entries in the correct quirky Intel format that the processor can 
understand.  Apparently it isn't that simple.

Since we have been talking about glibc and ELF issues this week, I've 
been thinking that we should consider moving the default application 
start address from 0x80000000 to the 0x00000000-0x7fffffff range that is 
used by every other OS I have worked with recently.  I suspect that the 
reason the kernel is loaded at 0x00100000 today is because it is 
slightly easier to bootstrap when you don't have to move the kernel from 
its BIOS-loaded location to its final destination in virtual memory. 
Since we're using GRUB, I don't think that's an issue any more.  Loading 
the kernel at 0x80000000 (2GB/2GB split) or 0xc0000000 (to give user 
progs. 3GB to the kernel's 1GB) would allow us to consider future 
support for loading foreign binaries, such as Linux programs (we are 
missing quite a few syscalls right now but FreeBSD has shown that it's 
possible) and WINE emulation.  Since the kernel's virtual address space 
is fixed (so that it can copy to/from all user address spaces 
efficiently), making this change sooner rather than later is important, 
even though no-one may get around to porting WINE for years.

I'm assuming that no existing Syllable app requires more than 1GB of 
virtual memory.  Since we don't have swapfile support right now, I think 
we would all notice if there was one!  This makes backwards 
compatibility easy because if we move the Syllable kernel up to 
0xc0000000 then we can give legacy apps that load at 0x80000000 at least 
1GB of address space, and possibly more considering that we now know 
they're actually shared libraries and not ELF executables.  New apps 
could be compiled as ELF executables with a dummy interpreter entry and 
a starting location of let's say 0x0400000 (since this is virtual 
address space, there aren't any holes in it, but it's good to leave the 
initial pages unmapped to catch null-pointer dereferences) and then 
we'll have a 3GB range for virtual memory.  Sound like a reasonable plan?

-Jake