Xref: utzoo comp.sys.atari.st:8022 comp.os.minix:2426
Path: utzoo!mnetor!uunet!mcvax!philmds!nlgvax!johan
From: johan@nlgvax.UUCP (Johan Stevenson)
Newsgroups: comp.sys.atari.st,comp.os.minix
Subject: Re: status of minix port to the ST
Message-ID: <215@nlgvax.UUCP>
Date: 2 Mar 88 22:17:02 GMT
References: <607UD138985@NDSUVM1> <214@nlgvax.UUCP> <157@bdt.UUCP>
Reply-To: johan@nlgvax.UUCP (Johan Stevenson)
Organization: Philips Research Geldrop
Lines: 90

In article <157@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes:
>In article <214@nlgvax.UUCP> johan@nlgvax.UUCP (Johan Stevenson) writes:
>>  Yes, the C compiler uses 32 bit addresses (and 16 bit ints), and can
>>  generate large programs. You can run programs as large as physical
>>  memory allows.
>This may have been hashed around before, but I never saw the final verdict,
>so please excuse me if this is "old news".
>
>Just exactly how will RAM memory be managed on the ST under MINIX?  On the
>PC I remember MINIX uses 64K offset addressing?  With absoulte addressing
>on the Atari some things must be different no?
	Indeed, 32 bit addresses and offsets. Inside the kernel and MM
	clicks of 256 bytes are counted in 16 bit ints, so 24MB address
	space. Physical and virtual addresses are identical.

>	1) does this mean a "fixup" table a la TOS and PC-DOS?
	The GEMDOS-style relocation info is appended to the loadfile and
	used during exec() to get the initial process image right.

>	2) what about swaping:
>		2a) a fixed "text" area, and a swap on each context switch?
>		    (don't laugh I've seen this proposed on the ST).
		Indeed, an in-core process image swap, but not often.
		In 99% of all cases this leads to 2 copies of the
		process image per fork(), instead of 1 for a machine
		with hardware relocation. Really!
		In pathological cases (look at the MINIX test programs)
		it takes many in-core swaps, but works. In practice, I
		only foresee problems with terminal emulators. Slight
		modifications to the code will be necessary for good
		performance.

>		2b) no swapping
		Then no fork().

>		2c) the "fixups" are remembered so the program can be
>		    relocated at run-time?
		Only works for text and read-only data.

>		2d) other
>	3) what about dynamic memory (e.g. malloc):
>		3a) Is there one heap, many, or something else?
		Fixed allocated area for stack and heap combined, like
		for MINIX-PC. However, you can choose this area as big
		as you like, as long as it fits in memory.

>		3b) can it be swapped/relocated/shared/overlayed?
		I do not fully understand the question.

>		3c) sbrk causes a swap (like V7)
		No.

>		3d) fragmentation problems?
		Like MINIX-PC.

>		
>	4) protection scheme?
>		4a) none
		None, except that low core is protected in user mode.
		(MM, FS, INIT and all user programs run in user mode).
		This, and the many faults detected by the 68000 as
		comapred to the 8088, give a reasonable protection
		against programming errors, NULL pointers, stack
		overflow and the like. So far I haven't seen a user
		process crash the system, although it is rather easy
		to create such a program on purpose.

>		4b) software integrity/ownership tests?
		No.

>		4c) other
		On process restart (when it is scheduled to run) a test
		is made for orange or red stack violation.

>-- 

In the documentation that comes with MINIX-ST a more extensive
explanation of the implementation details is given, including a
description of the technique called 'shadowing' that is used to
implement fork() and exec() with full UNIX semantics.


				Johan W. Stevenson,
				Philips Research Laboratories,
				Project Centre Geldrop,
				Building XR, Room 15,
				Willem Alexanderlaan 7B,
				5664 AN Geldrop, The Netherlands.
				phone: +31 40 892205
				uucp: mcvax!nlgvax!johan