[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Virtual Memory
Well AES applications tend to use small amounts of memory while system processes that need it could use a lot.
The idea of segmenting the memory and reserving an area for aes/vdi makes a lot of sense. I don't see the problem with doing it this way. I will attempt to do it this way, but I need to make anything work, to begin with, even without aes/vdi.
Thanks,
Mark
On Jan 12, 2013, at 7:53 AM, Jo Even Skarstein wrote:
> On Fri, 2013-01-11 at 10:42 -0500, Mark Duckworth wrote:
>
>> I really don't know what I'm doing but I am going to make an honest
>> effort to attempt to implement kernel support for virtual memory. I
>
> As Adam has already explained, the big, big problem here is how to get
> this working properly with programs that use the AES and VDI. These
> absolutely requires that both the system (AES and VDI) and clients use
> the same memory space. Also, how does MiNT knows which page(s) can be
> swapped and which can't (e.g. interrupt- or traphandlers)?
>
> It can be solved like Adam says by reserving a memory space (shared with
> the OS) for current applications, and put a new flag in the header for
> executables that are "VM-clean". But I worry about performance. Adapting
> the AES/VDI and clients to a VM model would require a whole new API. The
> RSC/OBJECT-tree would either have to be replaced with something new, or
> be accessed by the client through some API. Same with the shared AES/VDI
> structures. This will cost in terms of speed. I fear that AES/VDI
> applications would be restricted to "non-VM" also in the future.
>
> Sven Karlsson implemented virtual memory in MiNT 1.14 (or maybe it was
> in an early 1.15? I really can't remember, it's 15 years ago or so) but
> it really didn't work that well. I suggest you study his implementation
> to see what went wrong.
>
> Jo Even
>
>
>