Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
linguofreak wrote:
I'd define bitness by the bitness of the ABI provided to kernel modules (which will likely be the bitness of most of the code in the kernel): If kernel modules have to be 32-bit, it's a 32 bit kernel, even if there's a bit of 64-bit code to thunk to a 64-bit userland. The only exception I'd make to this is if the kernel requires a 64-bit CPU (rather than just being able to make use of one if present).
RDOS ABI supports 16, 32 and 64 bits. It's register based, and 16-bit code will typically extended pointers to 32-bit while the 64-bit module will allocate a 32-bit copy of pointers and copy page table entries,
The C/C++ API is constructed with inline assembly, and will vary depending on compiler,
rdos wrote:Of course a functional 32-bit kernel can be made to run 64-bit applications. ... The process is quite simple:
In short, to make a 32-bit kernel run 64-bit processes, just add 64-bit process support.
Still confused about what the discussion is actually about. You need to add 64-bit process support to be able to run 64-bit processes; AMD didn't design it backwards-compatible enough to run 64-bit software under 32-bit OSes without modification.
It goes both ways. In order for a long mode OS to run 32-bit processes you need to add support for 32-bit processes. Every executable format needs support in the kernel.
thepowersgang wrote:
On a side note - Would your ideas be switching between protected and long mode? Or running 32-bit kernel code in compatibility mode?
It could be done both ways. I switch between modes primarily because this allows the kernel to use call gates for 32-bit application kernel entry points. If I used compability mode instead, I'd need a common entry point, and a far call to 32-bit code from long mode.
