Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!ames!lll-winken!uunet!mcvax!hp4nl!phigate!prle!prles2!cstw01!meulenbr
From: meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks)
Newsgroups: comp.os.minix
Subject: Re: Blitter with fork
Message-ID: <458@prles2.UUCP>
Date: 28 Apr 89 08:29:43 GMT
References: <14044@louie.udel.EDU>
Sender: nobody@prles2.UUCP
Reply-To: meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks)
Organization: Centre for Software Technology, Philips Eindhoven
Lines: 30

In article <14044@louie.udel.EDU> HELMER%SDNET.BITNET@vm1.nodak.edu (Guy Helmer) writes:
>I don't have a 68000-based machine and I haven't programmed in 68000
>assembler for a couple of years now, so forgive this question if the
>answer is obvious.
>
>Why all the bother of swapping forked processes around in memory on an
>unprotected 68000 machine?  Why aren't memory references done relative
>to an arbitrarily assigned base register that Minix could change when a
>process forked?  A quick look at a table of 68000 instruction execution times
>revealed no obvious severe increase in execution times for address register
>relative addressing, and any performance penalties might quickly be recouped
>from the time saved if a large forked process was swapped even once.
>No flames please, just reasonable answers.
>-- Guy Helmer
>   BITNET: HELMER@SDNET         uucp: ghelmer@loft386

large processes won't exist in such an environment.
address relative addressing is limited to 64k, so in this case you're
facing a maximum process size of say 128k (64k text, 64k data),
unless you do something analogous to the large memory model on PC's
(yikes!), which is not done for minix/pc either.

I for me would rather prefer no size limitations.
This brings me to a different topic: has someone considered to 
implement disk swapping to minix. Might be interesting with a fast 
hard disk.

Frans Meulenbroeks        (meulenbr@cst.prl.philips.nl)
	Centre for Software Technology
	( or try: ...!mcvax!phigate!prle!cst!meulenbr)