I403%DMAFHT1.BITNET@cunyvm.cuny.edu (06/08/90)
Reply to "Musings on 386 Minix, and a Suggestion", by Tom Frauenhofer. Quotations marked by >>> ... <<<, since my editor doesn't allow me to do the usual > marking easyly :-( >>> Yesterday I priced 386SX systems. They are a hair cheaper than the 8086 I bought in 1986, about when Minix first hit the streets. I think that if a student in 1986 could affort an XT clone, then a student in 1990 probably can afford a 386SX clone. So here is my idea: <<< That's completely right. >>> - Let 1.5.10 be the "last" 8086/80286 version of Minix. It is quite a solid, full-featured Unix-style OS, and if all I had was an XT (which I don't) or an AT (which I do) then I would not feel orphaned. Of course, occasional bug fixes would be required for it. Do NOT add large memory model - by the time it is added, these chips will be even more obsolete. <<< (some stuff deleted) Not only that, even worse: running large model pgms in protected mode would probably be very slow, since reloading of segment registers takes a lot of time (and I don't expect a global optimizer that minimizes reloads over module (i.e. object file) boundaries :-). Segments are already a pain to implement in real mode. Beeing able to store pointers and longs completely in one register simplifies code generation and optimization significantly. Some ideas about the memory "model": I suggest having 3 segments set up: code,data,stack. The use of code (i.e. CS) and data (DS/ES/SS) is always known implicitly, so pointers will be 32 bit. I think one could still archieve automatic stack growth by logically separating the data segment in two halfs (or some other fraction) at the paging level: The "data" part will only grow (i.e. have the pages allocated) due to "sbrk" calls, whereas the "stack" part would automatically be increased (and perhaps sometimes decreased) whenever a page fault in this area occurs that is reasonably interpretable as stack growth (e.g. it is very unlikely increasing from 5 KB to 1 GB at once - but this might be debated upon). Allocation and access to variables known to be "auto" would always be through SS, addresses would always be used via DS (which would have a constant (compiler-known) offset to the start address of the stack, e.g. using the high-bit as toggle when having two halves). Translation would only be needed to get the address of an auto var. So it should even be possible to detect "wild" addresses easyly. To be clear, I haven't yet programmed an 80x86 for x > 2, but everything I've read makes me think such a solution should work. Of coures, I might err. +-----------------+ <--- DS/ES:0 | | | | increasing offset | static data | | | | V +-----------------+ <--- SS:0 = DS:0x80000000 | | | auto data | | | +-----------------+ >>> I know that other people have other opinions on this topic, I would love to see some serious discussion, not a flame war (like some of the Minix versus Coherent nonsense). This is a serious proposal/suggestion, and I realize Dr. Tanenbaum has the final say. You could e-mail me, but I would rather see this posted to the net. <<< I do also agree. Here you get it. >>> And thanks, Dr. Tanenbaum, for a nice Unix-like operating system (and some well-written books. <<< Of course, I do also agree about that. Marc Wachowitz (a.k.a. Smalltalk on RELAY) I403@DMAFHT1.BITNET