[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Virtual Memory



Hi,

On sunnuntai 13 tammikuu 2013, Mark Duckworth wrote:
> 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.

Program's give "random" memory address pointers to AES functions,
they may point to program heap, stack, BSS, data, or even code section
depending on how the pointed memory is defined in the program source,
and what compiler does (e.g. VBCC can put data into text section so that
short relative addressing modes can be used).

How do you segment something on which you don't have control?


> I will attempt to do it this way, but I need to make anything work,
> to begin with, even without aes/vdi.


	- Eero

> 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