Path: utzoo!attcan!uunet!mcvax!hp4nl!botter!star.cs.vu.nl!ast@cs.vu.nl
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: MINIX for the 386
Message-ID: <1836@ast.cs.vu.nl>
Date: 20 Dec 88 14:50:13 GMT
Sender: ast@cs.vu.nl
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 73


The subject of the 386 has come up several times recently.  It is my
understanding that 1.3 should work on most vanilla 386 boxes.  However, the
question remains about virtual memory, using protected mode, etc.  Some
thoughts on the subject.

It is very unlikely that MINIX 2.0 will go native on the x86 (x=2, 3).  It
will be enough work just incorporating all the recent (and future) fixes,
software etc. and having a go at POSIX compatibility.  My goal is still to
keep it simple enough for students to understand it.

With respect to others who want to hack it to use paging etc., I would suggest
keeping the following firmly in mined.  The 386 developers are free to change
everything everywhere and then distribute diffs against 1.3.  However, at some
point in the future, 1.3 may be considered obsolete, and people will want
diffs against 2.0.  The best way to make sure this is not a huge amount of
work is to be conservative and change as little as possible, and make those
changes as localized as possible.  For example, I would suggest forgetting
about mapping files into the address space as it requires major changes to
the file system.  Similarly, I would forget 16 of the 386's 48 address bits
and just concentrate on making a virtual memory system that uses a single
32-bit segment.  In effect, this simulates the 68020, and should make porting
to 68020 (68030) systems straightforward.  I would also suggest really making
an effort to resist changing anything that doesn't really have to be changed
in the name of compatibility.  For example, the whole business of keeping
track of memory in clicks is probably viable if you just set the click to the
page size instead of 16 bytes.

Files that have only a few changes should be marked #ifdef i386 in analogy
with the current #ifdef i8088.  Avoid using #else, since #ifdef may be any of
8088, 80386, Atari, and (eventually) Amiga.  Try to put large chunks of new
code as procedures in a separate file.  Thus I can imagine some procedures
becoming:

xxx()
{
#ifdef i386
   foobar()
   return;
#endif

  ... original code ...
}

or something like that.  If whole files have to be replaced, just replace
them and change the makefile.

In short, I am making a plea for making an effort to take compatibility fairly
seriously, and make as few changes as possible, and make these as cleanly as
possible so that they can be transferred to 2.0 when the time comes.   In 
principle I am willing to make the 386 stuff a permanent part of the system,
but only if it fits in well.  The Atari FS and MM are examples of where this
has happened.  The changes needed for the Atari are minor, so there is one
FS that is good on PC and ST, and one MM for PC and ST.  This is not true of
the kernel unfortunately.  Looking at the 1.3 FS and MM is a worthwhile
exercise.

The Vrije Universiteit is going to start working on a 386 compiler soon.
Whether this will fit on the 8088 is as yet unknown.  We have an ANSI standard
C compiler, and it definitely does not fit in the 64K + 64K model, so 2.0
will continue to use the K&R-compatible compiler now in use, at least for the
8088.

The 286 has such an awful architecture that I am not inclined to cater to it
at all, despite the fact that my own machine is a 286 and our department has
a room full of them.

Another thing: please stick to the original programming style in terms of
layout, comments etc.  It looks funny to have mixed styles all over the place.
I posted a document on MINIX-style some time ago and can send a copy to
anyone who missed it.

Andy Tanenbaum (ast@cs.vu.nl)