jerry@polygen.uucp (Jerry Shekhel) (07/24/89)
Hello all. I realize that implementing a protected-mode compiler is not as easy on the 286 as on most other processors, but it CAN be done, and the effort might be worth it. I also realize that this is going beyond the strictly educational purposes of MINIX, so the compiler does not have to be packaged with the standard distribution. The reason I'd like to see a large-model compiler is to make possible the implementation of something like a windowing system for MINIX. Just as I have doubts about the utility of a windowing system without multitasking (like the Mac Finder), I really see very little use in (single user) multitasking without a windowing system. Having several windows on the screen with a shell executing in each would be the ideal application of MINIX multitasking. Also, a windowing system would open up many MINIX development doors, and at least for me, it would create INTEREST in MINIX development. As it stands now, I find myself using MINIX too much like MS-DOS too often, not utilizing MINIX multitasking at all.
ncoverby@ndsuvax.UUCP (Glen Overby) (07/29/89)
In article <505@polygen.UUCP> jerry@polygen.uucp (Jerry Shekhel) writes:
[... about wanting a protected-mode compiler]
If you need a medium or large model compiler, why not use one of the many
MS-DOS based compilers? You'll need to hack the memory manager to use more
than 64K/64K, so why not .EXE format? It would make communicating with the
DOS world much easier.
I recall the people using MS C and Turbo C saying that it was faster to
compile under dos and convert over (including rebooting Minix) than to run
ACK and asld. Of course, you'll pay more for the comiler than you did for
Minix :-)
--
Glen Overby <ncoverby@plains.nodak.edu>
uunet!ndsuvax!ncoverby (UUCP) ncoverby@ndsuvax (Bitnet)jca@pnet01.cts.com (John C. Archambeau) (07/30/89)
It's a bit more than simple hacking of mm...
The problem is that the Minix kernel doesn't support large model programs.
The memory management task needs to be rewritten as well. Also the a.out
header needs to be modified and not to mention the function load_seg needs to
be rewritten. It's all all in the compiler. You also have to make Minix
aware of the fact that you can have these huge programs from hell that can be
forked, execed, et. al. And yes, it is faster the compile under the MesS-DOS
C compilers, but then there's that problem, how does the MesS-DOS world keep
track of large programs? And under 286 protect mode, that's another ball game
entirely, DOS doesn't want to have a thing to do with 286 protect mode and
none of the DOS C compilers generate 286 protect mode code. Certainly they
generate 286 protect mode instructions (at least TC does), but where's the
protect mode? It ain't there. Another side note, MS-DOS C compilers also
optimize a helluva lot better than Minix C...especially if you compile to the
186/286 instruction set. This is a very viable thing to do since you
chop 20K off the size of the image. Note to you NEC V20/V30 people, you have
the 186/286 instruction set, so if you want to save 20K on your image size, do
it. It works with Turbo C 1.5.
/*--------------------------------------------------------------------------*
* Flames: /dev/null (on my Minix partition)
*--------------------------------------------------------------------------*
* ARPA : crash!pnet01!jca@nosc.mil
* INET : jca@pnet01.cts.com
* UUCP : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
*--------------------------------------------------------------------------*/