Re: [Freemint-discuss] Virtual Memory Implementation Ideas

[Thorsten O. <ad...@th...>]

On Montag, 8. Mai 2023 04:55:46 CEST Mark Duckworth via Freemint-discuss 
wrote:
> You will
> be able to specify your virtual address space but I will choose
> 0xbdffffff-0xfdffffff as an example.

Using an address space that is negative will not be the best idea. Malloc() 
for example will then return such addresses, and that might be interpreted as 
failure.

>Now the question is, what is my idea missing?  Is this viable?

I think you forgot the most important thing: virtual memory means that 
addresses of user programs and the kernel are no longer the same. That means 
that all such addresses cannot longer be directly accessed by the kernel, and 
you have to use special functions to copyin such parameters from user-space, 
and copyout back to it. That might be doable in the GEMDOS interface, but i 
think will be hard to do in the BIOS and XBIOS interfaces. It will also 
disallow user programs to use Supexec and/or Super() in most cases. But the 
most troublesome part is the AES, when it tries to access deeply nested 
structures. It also applies to any GEM protocols used, since addresses of one 
process are different from others. So basically i think, virtual memory cannot 
be supported for GEM programs at all (or at least not without heavy 
modifications).