Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!tut.cis.ohio-state.edu!bloom-beacon!think!husc6!mailrus!uflorida!haven!cvl!mimsy!jds
From: jds@mimsy.UUCP (James da Silva)
Newsgroups: comp.os.minix
Subject: Re: Bruce Evans' opus
Message-ID: <17779@mimsy.UUCP>
Date: 29 May 89 13:54:30 GMT
References: <2570@ast.cs.vu.nl> <216@bilver.UUCP>
Reply-To: jds@mimsy.umd.edu (James da Silva)
Organization: University of Maryland, Department of Computer Science
Lines: 51

In article <216@bilver.UUCP> wbeebe@bilver.UUCP (bill beebe) writes:
> ... One other thing
>you need to think about, Mr. Tanenbaum, and I'll draw a picture to help
>illustrate my point.
>
>  +-------------------+---+---+---+---+----------------+
>  | BASE 31...24      |23 |22 |21 |20 |  LIMIT 19...16 |
>  |                   |G  |X  |O  |AVL|                |
>  +-------------------+---+---+---+---+----------------+
>
>It's a crude picture of the upper 16 bits of the 80386 descriptor quad
>word. The high 16 bits were zero in the 80286, but in the 80386 we have
>four more bits in the limit field and eight more in the base. If we lave
>the base alone, the segment limit is now 1 meg, not 64 K. Using the current
>AT Minix architecture, that means programs can span 2 megs; 1 meg for code
>and 1 meg for data. It also means that segments have a one byte granularity.
>Using the base and setting the granularity bit, we can have segment limits
>up to 4 gig with a granularity of 4K bytes. I find your reasoning why
>Bruce Evan's work will cause a split to be flawed and technically
>imcompetent. 

Bill,

I must be even more imcompetent (sic) than Dr. Tanenbaum, as I don't see
your point at all.  Could you draw me another picture?

Seriously, the fact is that it is tricky for a 32-bit kernel to support
16-bit processes.  And out of the question for a 16-bit kernel to support
32-bit processes.  So what choice do we have?  The 16-bit and 32-bit
kernels have to be different binaries, at least.  The sources can be
largely the same, if you are very careful.  But not entirely the same.

So, should the PC Minixers have to carry around the extra complexity
required to support protected mode, in the base Minix release?  I don't
think so.  I think this was all Dr. Tanenbaum was trying to say.

Then, should we cripple the 32-bit kernel to increase compatibility with
the PC version of Minix?  I hope not!

Should Prentice Hall market ANOTHER version of Minix for the protected
mode?  Maybe, but who cares?  How would it help you or me?

Now, does this mean that we won't have 32 bit Minix for our 386's until
Prentice Hall and AST decide to do it?  No, of course not.

Nit Pick: Bit 21 of the descriptor is not `O', it is `0', as in Undefined.

Jaime
...........................................................................
: domain: jds@mimsy.umd.edu				     James da Silva
: path:   uunet!mimsy!jds