Xref: utzoo comp.sys.atari.st:7945 comp.os.minix:2410
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!unisoft!gethen!bdt!david
From: david@bdt.UUCP (David Beckemeyer)
Newsgroups: comp.sys.atari.st,comp.os.minix
Subject: Re: status of minix port to the ST
Message-ID: <157@bdt.UUCP>
Date: 29 Feb 88 21:18:31 GMT
References: <607UD138985@NDSUVM1> <214@nlgvax.UUCP>
Reply-To: david@bdt.UUCP (David Beckemeyer)
Organization: Beckemeyer Development Tools, Oakland, CA
Lines: 32

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?
	1) does this mean a "fixup" table a la TOS and PC-DOS?
	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).
		2b) no swapping
		2c) the "fixups" are remembered so the program can be
		    relocated at run-time?
		2d) other
	3) what about dynamic memory (e.g. malloc):
		3a) Is there one heap, many, or something else?
		3b) can it be swapped/relocated/shared/overlayed?
		3c) sbrk causes a swap (like V7)
		3d) fragmentation problems?
		
	4) protection scheme?
		4a) none
		4b) software integrity/ownership tests?
		4c) other
-- 
David Beckemeyer			| "To understand ranch lingo all yuh
Beckemeyer Development Tools		| have to do is to know in advance what
478 Santa Clara Ave, Oakland, CA 94610	| the other feller means an' then pay
UUCP: ...!ihnp4!hoptoad!bdt!david 	| no attention to what he says"