HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (05/03/90)
Since it is agreed that MINIX/PC is a toy mainly due to the process space limit, a new hardware baseline is needed to put INTEL-MINIX on. Since PC's are being replaced by AT's and - much quicker - AT's will disappear and be replaced by 386SX machines - MINIX should be ported to the 386SX quickly. I don't like INTEL processors (I am 68000-Fan), but at the moment 386SX machines provide most power at a meanwhile moderate price. Once a true 32-bit compiler/assembler for the 386 is ready, I think the MINIX-ST implementation is the starting point to choose: As a first step, map a single 32-bit address space shared by all processes - this is the situation on the 68000 so we need shadowing - and, when this runs, exploit the MMU for relocation and protection. It is my opinion that it makes no sense porting PC-MINIX to 80286 protected mode. It is better to go to the 80386 - 80x286 is brain-damaged for x<3. Though I am not an expert in INTEL processors, I feel that all the 386 work carried out at the moment should converge somehow, and that it is time to cut a clear line between 80386 MINIX and PC/AT MINIX. Christoph van Wuellen.
jca@pnet01.cts.com (John C. Archambeau) (05/04/90)
I do agree with you on the '286 architecture. The 386 doesn't need shadowing
since it can flip memory wherever it chooses (386's can support LIM EMS 4.0
without any external help, most 386 BIOS chips have the interrupts to handle
this embedded within them, and since the 386 has no problems going in and out
of protected mode and virtual 86 mode, it works like a charm). You can also
add demand paging to the 386 as well...true virtual memory. So Minix 386
would be a quantum leap and it would make it a 'real Unix.'
// JCA
/*
**--------------------------------------------------------------------------*
** Flames : /dev/null | Xenix is the ONLY thing
** ARPANET : crash!pnet01!jca@nosc.mil | Microsoft did right.
** INTERNET: jca@pnet01.cts.com
** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
**--------------------------------------------------------------------------*
*/zt0009%DMSWWU1C.BITNET@cunyvm.cuny.edu (Kai Henningsen) (05/08/90)
> Since it is agreed that MINIX/PC is a toy mainly due to the process space > limit, a new hardware baseline is needed to put INTEL-MINIX on. > Since PC's are being replaced by AT's and - much quicker - AT's will > disappear and be replaced by 386SX machines - MINIX should be ported to > the 386SX quickly. Exactly. > I don't like INTEL processors (I am 68000-Fan), but at the moment 386SX > machines provide most power at a meanwhile moderate price. Once a true > 32-bit compiler/assembler for the 386 is ready, I think the MINIX-ST > implementation is the starting point to choose: > > As a first step, map a single 32-bit address space shared by all processes > - this is the situation on the 68000 so we need shadowing - and, when this > runs, exploit the MMU for relocation and protection. > > It is my opinion that it makes no sense porting PC-MINIX to 80286 protected > mode. It is better to go to the 80386 - 80x286 is brain-damaged for x<3. You are quite right re: brain damaged. However, let me point out that a better way would be a mixture of the current ST and PC versions, that is, keep the PCs segments (thus getting a separate adress space for every process), but make those segments (that is, 1 Code & 1 Data segment) LARGE (i.e. 32 Bit). I think that the 286 version already includes everything interesting re: this. In a later step, introduce paging. To prepare for this in advance, consider allocating all memory in 4K chunks which can later be pages (that is, make a click be 4KB). > Though I am not an expert in INTEL processors, I feel that all the 386 work > carried out at the moment should converge somehow, and that it is time to > cut a clear line between 80386 MINIX and PC/AT MINIX. Agreed completely. Do NOT include a compatibility mode; since we have all the sources, there is no need for binary compatibility (which does not exist with other versions of MINIX either). > Christoph van Wuellen. Kai Henningsen zt0009 @ dmswwu1c . bitnet
jburnes@crash.cts.com (Jim Burnes) (05/08/90)
Christoph:
I wholeheartedly agree. Po{ting MINIX to the 386 and then establishing
the 386sx as the new baseline would be a tremendous draw to MINIX. MINIX
on a 386 machine would instantly turn it into a serious experimenters
OS. I beleive Bruce Evans is the man to talk to here. With some luck we
could release the 386 protected mode version for all.
Jim Burneskjh@pollux.usc.edu (Kenneth J. Hendrickson) (05/08/90)
While I think it would be a good idea to produce a version of Minix that can take advantage of the increased capabilities of the '386, I also think that it is important to continue support for the '88, '86, and '286. The original idea was to produce an operating system that students can play with, and learn from. Many students aren't rich enough to have a '386 platform. Another note: I'm not far enough along in the upgrade process to make any meaningful comments about how to do it, but I would like to see support for the 'x87 math co-processors. Perhaps I will write it and post it if it hasn't already been done. I envision that a flag can be set if 'x87 co-processor support is desired, during compilation. The naive user shouldn't be any the wiser, and the co-processor should be used if it is there (and the operating system knows about it.) Ken Hendrickson N8DGN/6 kjh@usc.edu ...!uunet!usc!pollux!kjh
jca@pnet01.cts.com (John C. Archambeau) (05/09/90)
kjh@pollux.usc.edu (Kenneth J. Hendrickson) writes: >While I think it would be a good idea to produce a version of Minix that >can take advantage of the increased capabilities of the '386, I also >think that it is important to continue support for the '88, '86, and >'286. The original idea was to produce an operating system that >students can play with, and learn from. Many students aren't rich >enough to have a '386 platform. > >Another note: I'm not far enough along in the upgrade process to make >any meaningful comments about how to do it, but I would like to see >support for the 'x87 math co-processors. Perhaps I will write it and >post it if it hasn't already been done. I envision that a flag can be >set if 'x87 co-processor support is desired, during compilation. The >naive user shouldn't be any the wiser, and the co-processor should be >used if it is there (and the operating system knows about it.) Yea, but a lot of them can afford 386SX's. I should know, I am one. :) But of course, I'm working too as well. // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | Xenix is the ONLY thing ** ARPANET : crash!pnet01!jca@nosc.mil | Microsoft did right. ** INTERNET: jca@pnet01.cts.com ** UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */