Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!purdue!gatech!hubcap!ncrcae!ncr-sd!crash!pnet01!jca
From: jca@pnet01.cts.com (John C. Archambeau)
Newsgroups: comp.os.minix
Subject: Re: Direction of MINIX
Message-ID: <4325@crash.cts.com>
Date: 9 Jun 89 00:56:11 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 48

The problem with a large model compiler is how are large model programs going
to be maintained by Minix?  It's not the compiler that's going to be the
problem, it's juggling around the code and data segments of the program by the
kernel.  The fact that the kernel keeps track of one code segment and one data
segment under the current Minix makes live hellishly simple.  All the compiler
does is generate code, the linker will arrange the segments in some order that
makes it manageable under Minix.  So before you people start chanting 'large
model' compiler, I want to hear the following;
 
1. How are the segment registers going to be maintained?
 
2. Are there going to be memory models (ala MesS-DOS C), and if so what
   are they?

3. How will pointer types be handled?  This is a big problem under
   MesS-DOS C compilers with your near, far, and huge pointers.  And will
   each memory model have a default pointer size?

I agree that a large model compiler is highly desireable, but how is the
kernel going to handle large model programs?  When this question is answered,
then a large model compiler will be a reality, but you can't really do a thing
until that question is answered.  I also have it on fairly good authority that
GCC can not be ported over to 80x86 (where x < 3) machines easily.  Some have
considered the thought to be more trouble than its worth.  The problem is the
64K segments, with large model programs, they get in the way.  I believe that
the 'real' versions of 80x86 UNIX handle the large model problem just by
making shared code segments, which is more of a hack than a real answer to the
problem at hand.  I have no qualms about writing a C compiler myself for
Minix, but to achieve this large model business, some of us will have to
decide exactly how 8086/80286 Minix will handle large model programs.  Memory
and process management for multiple code and data segments for a single
process won't be fun, but I'm pretty sure it is doable, and if done correctly
it might even run quite nicely.  Once all of these problems have been handled,
a bare bones ANSI C compiler with simple peephole optimization won't be far
off.  The lexer and parser for shareware/PD ANSI C compilers can be pulled for
the new Minix C and the only thing that needs to be written is the back end of
the compiler.  Later, if any of us have any brain cells or sanity left, more
optimization can be done to produce nice tight code.

 /*--------------------------------------------------------------------------*
  * That's not an operating system, this is an operating system!
  *--------------------------------------------------------------------------*
  * UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca
  * APRA: crash!pnet01!jca@nosc.mil
  * INET: jca@pnet01.cts.com
  *--------------------------------------------------------------------------*/
  
#include <disclaimer.h>