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

RE: MMU questions?



	>Can the MMu work in both ways, Memory protection ON AND virtual
	> memory?

	Yes. However there is a problem concerning this. TOS, and MiNT
	for that matter, only define 2 types of memory ST-RAM and
ALT-RAM
	aka TT-RAM. Programs often regard both as non-virtual memory.
This
	causes a problem when incoperating virtual memory into the
system
	as well as to a minor extent when incoperating memory protection
into
	MiNT. For instance programs must not put interrupt and similar
code into
	virtual-ram since this could lead to a reentrant virtual memory
handler.
	Furthermore an interrupt handler  must not touch any virtual
memory.

	A typical simple example.

	1. A program cause a  page fault and the virtual memory manager
starts
	   working.
	2. When the VMM is working an interrupt occurs.
	3. The interrupt cause a page fault.

	Now you have two pending page faults simultainously. This is not
good
	and cause quite a few headaches since the interrupt should have
higher
	priority than the program. Disabling interrupts in the VMM is
not a viable
	solution since handling of a page fault could take milliseconds.
Disabling
	interrupts would more or less stall the entire system during
that time. Instead
	the VMM should interact with the scheduler so that other
processes are run
	when the VMM is waiting for data from the hard disc.

	> If so, why can't outside work with memory protection? coz it
might
	> just check for the simple cookie MMU only? could it better
check or
	> just that it is plain impossible ? (combining vmem and mem
protection)

	If Outside would support memory prtection it would need to be
rather
	closely coupled to the kernel which is hard since it was
designed to
	work with TOS.

	> 2) Is the Vmem (on Falcon for example or TT without TTram)
seen as
	> TTram? or ALT RAM? 
	> hence do you have 3 types of RAM on TTram computer equiped? 
	> like, is it possible to have a TT with 4 of STram, 8 meg of
TTram and
	> 10 meg of vmem?
	> If yes, what tool shows that correctly?

	You only have ST-RAM and a larger TT-RAM. 

	> 3) what is the correct pointer containing the MAX TTRAM
(physical)?
	> and MAX Vmem?

	There is a system variable that shows how much TT-RAM or virtual

	memory that is installed. There is currently no easy way of
inquring
	how much  virtual memory and TT memory there is. However all
	virtual memory systems I know of replace all of the TT-ram with
	virtual memory.  

	The most clean and easy solution to this to add a third type of
memory
	i.e. virtual memory that programs can use for everything that
don't need
	DMA access ,and thus should be in ST-ram or need to be reachable
from
	interrupts, and thus should be in TT-ram or ST-ram. 

	However this is of no or very little use for the existing
codebase that assumes
	that TT-ram is valid to be used for interrupthandlers.

	The same problems apply for GEM programs and programs that use
cookies
	in a certain way ie programs that allows other programs to read
memory from
	them directly by passing them a pointer. This is a clear
violation of memory
	protection. No program should encourage other program to read or
write into
	its memory space. However this is the case when some programs
put a pointer
	to a datastructure inside the programs private memory into a
public cookie.
	This is also commonly the case when the VA protocol is used. 

	There are numerous examples, I'm sorry to say that I'm sometimes
partly responsible,
	of de facto standards for clean Atari programs that are
altogether totaly braindamaged
	when it comes to extending TOS for memory protection, virtual
memory, multi-tasking, 
	multi-threading, shared libraries, object orientation and other
nifty techniques and features
	that we should have thought of in the first place.

	Sometimes I get this depressing thought that Digital Research,
RIP, made this mervellous
	operating system and handed it over to Atari and the rest of us
to wreck it totally.

	However both Microsoft and Apple seems to have made basically
the same misstakes...

	Yeah, I know I'm a cynical person but then again being cynical
makes it possible for
	me to carry on coding on Fenix which I hope will solve some of
our problems once
	and for all.

	Regards
	 Sven