arno@cbmnlu1.cbm.nl (Arno Griffioen) (05/02/91)
I've been hearing some rumours lately about a MINIX version that can use more than one segment on a 286 in protected mode. Anyone got any pointers? I always heard that it wasn't impossible, but that a major rewrite of MM was nessecary and the performance would probably suffer (a lot). Bye Arno.
leisner.wbst139@xerox.com (05/03/91)
I did an implementation of protected mode Minix on a 286. It basically was a mess. The C compiler needs to do stuff with multiple segments (I used Aztec as a cross-compiler, so the compiler really was no problem for me). The memory manager needs to be changed. Addresses would need to be extended between applications and kernel to [segment:offset] instead of just offset. This would allow things like putting data (strings) in text instead of always in data. I basically wanted a model with 64k code, 64k data, 64k heap/stack; which I found very difficult and incompitable with anything. The 286 also had bugs (I had my HP analyzer on the socket, was watching the bus and several things Intel defined between levels of protection didn't work as defined). The 286 is basically a bastard machine. I'd much recommend getting a 386 with a linear address space and forgetting about segments. There is far too much work involved for marginal gain. marty (Knowledge is useful in the Information Age) (Software is mindstuff. It is the hardest activity created by man) ARPA: leisner.henr801c@xerox.com NS: leisner:henr801c:xerox UUCP: hplabs!arisia!leisner
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) (05/19/91)
arno@cbmnlu1.cbm.nl (Arno Griffioen) wrote: > I've been hearing some rumours lately about a MINIX version that can use > more than one segment on a 286 in protected mode. Correct. > Anyone got any pointers? I always heard that it wasn't impossible, but > that a major rewrite of MM was nessecary and the performance would probably > suffer (a lot). Not really. Currently, MM and the kernel parts of the memory manager only allocate one (1) segment for code, one (1) for data and ditto for stack. Someone in The Hague (nah- won't tell his name here) did a very good job in changing this. He used my version of MINIX, and added support for up to 16 segments (x 3, of course) per process. He now cross-compiles a "large" program like my port of Borland MicroCalc II, and converts it to MINIX a.out (also with a new magic) format. This can be run on MINIX. The problem is, of course, the compiler. The poor thing has to decide when to use inter-segment calls and jumps, and when to use intrasegment ones. Same goes for memory ("data") references. Of course, a call to a function in the same segment is faster than a similar call to a function in another segment. Alas, that is the Joy of a Small iNTEL machine... :-( The guy I am talking about is planning on a pre-alpha test version by the end of this month (May, isn't it?). I will summarize here, although I doubt his willingness to post the stuff here... more about that later. Fred. -- MicroWalt Corporation, for MINIX Development waltje@uwalt.nl.mugnet.org Tel (+31) 252 230 205, Hoefbladhof 27, 2215 DV VOORHOUT, The Netherlands "An Operating System is what the _USERS_ think of it- me"
windy@shiva.informatik.rwth-aachen.de (Andrew John Stuart Miller) (05/23/91)
waltje@uwalt.nl.mugnet.org (Fred 'The Rebel' van Kempen) writes: >The problem is, of course, the compiler. The poor thing has to decide >when to use inter-segment calls and jumps, and when to use intrasegment >ones. Same goes for memory ("data") references. >Of course, a call to a function in the same segment is faster than a >similar call to a function in another segment. Alas, that is the Joy >of a Small iNTEL machine... :-( I doubt one would want to make this official, but the compiler and the oerating could both benefit from an idea from OS9. Procedures defined and used in the program source could be compiled into the usual user segments. Library proceudures could be compiled into memory resident modules, which the compiler knows will always be far calls. This brings the following advantages code and data segments could be smaller => larger processes possible modules could be shared between programs eg vi origami grep and emacs and (etc) could all share a regexp module vi origami and emacs share curses all programs share stdio etc. (bad example, but you get the idea?) This together with shared text, which has already been done for iNtel would mean that a high degree of multiprogamming can be done even in 640k There is of course a cost:- many things run more slowly. A new linker is needed. (ie as ld etc new to cope with modules) mm needs to be modified to keep track of modules in store. exec needs to be modified to perform run time linking of modules (?) ( the addresses of the segments for the modules depend on the configuration how many modules are loaded, the order of loading etc....) This is something I keep on meaning to get round to doing, but:- a) I haven't got the time b) I'm giving up using Intel processors for mental health reasons! If I do get round to it, I will post it.... Andrew