ast@cs.vu.nl (Andy Tanenbaum) (12/20/88)
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)wbeebe@bilver.UUCP (bill beebe) (12/23/88)
In article <1836@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >The subject of the 386 has come up several times recently... >... 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. The mode your talking about is called Flat, or Motorola, mode. In that mode the base address in the descriptor is set to zero, and the limit is set to all binary ones. The granularity bit is set so that the limit is in 4K byte pages, not single bytes. What this buys is the creation of only one set of descriptors that are loaded when the kernel first boots, and remain untouched after that. With just a *little* work, the descriptor for the stack can be segragated from the rest of the data and code descriptors so that some protection from stack over-run (and subsequent code/data corruption) can be enforced in the hardware. There are a few examples on how to set the 80386 family up in flat mode. >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. I agree. The 80386DX and 80386SX provide solutions to the problems that drive mad men crazy when they try to program 80286 PM. I might also remind you that the 80486 is Real Close Now :-).
brucee@runx.ips.oz (Bruce Evans) (12/27/88)
I think my 386 port follows Andy's guidelines well. My diffs for mm are only 6K, and for fs only 2K, and most of this is for stuff done non-portably in the first place. I don't think we have benefited enough from the Atari port though. Changing the click size from 16 to 256 didn't quite work since there is some segment arithmetic also using the magic 16. I would like to see a summary of PC/Atari Minix kernel differences (except drivers). And are the mm/fs/commands really much the same? There seem to be a lot of old PC bugs cropping up again in the Atari postings. The Minix coding style guidelines did not reach here. Please repost them. I have some problems with the style, mainly indenting a full tab stop at a time and contortions to avoid this going off the page, and the ugliness that has crept in from not updating comments with the code (ornate comments tend to produce larger diffs than code). Also, elle with linewrap wraps at column 78, messing up the formatting. Bruce Evans Internet: brucee@runx.ips.oz.au UUCP: uunet!runx.ips.oz.au!brucee