Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!samsung!munnari.oz.au!metro!ipso!runxtsa!brucee
From: brucee@runxtsa.runx.oz.au (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: 386 Memory Management
Message-ID: <1827@runxtsa.runx.oz.au>
Date: 4 Jun 90 12:52:53 GMT
References: <611@philica.ica.philips.nl>
Organization: RUNX Unix Timeshare.  Sydney, Australia.
Lines: 30

(Please send any reply to this to my other address, evans@ditsyda.oz.)

In article <611@philica.ica.philips.nl> adrie@.ica.philips.nl () writes:
>I don't know whether there's only one 32-bit 386 Minix implementation
>under development (Bruce), or maybe other guys are trying as well to
>get Minix running in 32-bit mode? What I would like to know is how

The only implementation independent of mine that I know about is by a group
with ari@hut.fi. Some people are attempting to cross-compile my stuff. I
can build it native using gnu tools.

>I'm working on a Minix port to a Sparc computer and assign each process
>a continuous piece of physical memory and map it at virtual address 0.

That's about all I'm doing. The mapping is done with segments as in 1.5.10
(zero changes to MM). It runs in paged mode, but only to map some RAM below
640K to make all (non-kernel) RAM is contiguous (so gcc fits :-).

>process runs. Not on stack-faults nor BRK system calls. I still have to
>use the `chmem' program and decide by try and error what the initial gap
>should be (I had to increase the gap for the GNU C-compiler to 700000
>and the assembler to 500000 to be able to compile big programs).

Same :-(. Recompiling gcc requires chmem =1150000. I only have 2M and with
gcc that big, make no longer fits.

Bruce Culbertson implemented paging for Minix on a 32K. It has complications
like a 512 byte h/w page size and a 1K s/w page size. I have been meaning to
use some of the code for that for almost a year but have been doing too much
busywork for 1.5.x.