Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!tank!mimsy!jds
From: jds@mimsy.UUCP (James da Silva)
Newsgroups: comp.os.minix
Subject: Re: ibm process size
Message-ID: <16021@mimsy.UUCP>
Date: 18 Feb 89 17:43:45 GMT
References: <134@cbnewsl.ATT.COM>
Reply-To: jds@mimsy.umd.edu (James da Silva)
Organization: University of Maryland, Department of Computer Science
Lines: 61


In article <134@cbnewsl.ATT.COM> mjs@cbnewsl.ATT.COM (michael.j.scheutzow) writes:
>....  The hardware directly supports separate segments for code, data and
>stack.  This means (in theory) that minix processes could be as large as 192Kb
>without having to resort to far pointers.

Don't forget ES, the `Extra Segment' register!  This gives us 256k without
far pointers, in theory.  This isn't practical, however.  C doesn't
distinguish between the stack and data `segments'; all data must be in the
same address space.  The same code must be able to handle being passed the
address of a local variable (in the stack), and a global one (in the `data
segment').  How can the code tell which segment to access?  So, 64k code
plus 64k data/stack is the practical limit for 8086 `small' model.

>The problem with theory, of course, is that it makes life hard for c-compiler
>writers.  The easiest compiler to implement essentially ignores this segment
>hardware by dumping the code, data and stack into one 64Kb area (guess which
>approach is used by the pc-minix v1.2 compiler?)
>
>The next best thing to do is assign the code to one segment and the data+stack
>to a second segment.  AST says that minix supports this configuration, if you
>can find a compiler (and libraries) that generate it!  This type of program
>can be as large as 128Kb, and I find it considerably less restrictive than
>what we are currently using.

Then you will be happy to know that the Minix assembler DOES support split
I&D, as of Minix 1.2, with the `-i' flag.  The compiler (and thus the
libraries) doesn't care, as it generates assembler code that looks
something like this:

	.code
_func:
	<some code here>
	.data
_datum:
	<some data here>
	...

It never counts on particular addresses for data or code.  All near jumps
and calls are relative to the CS register, data accesses relative to
the DS register.  The SS register (stack) is used for local vars and by the
hardware for CALLs and RETs.

The upshot is that the compiler doesn't care whether CS == DS at runtime
(the assembler cares).  It does require that DS == SS, as the offets of
local stack variables have to be reachable with DS.  

Everyone who is confused should go read Appendix B of The Minix Book.  This
is a good quickie intro to the 8086 and PC architecture.  There is one
error related to this discussion, however.  On page 368 Andy writes:

    "In all cases, the address computed by adding the contents of BP to
    a constant is relative to DS (which is always equal to SS in MINIX)."

This is backwards.  BP-indexed addressing is relative to SS, which happens
to equal DS in MINIX.  Yes, I'm nit-picking.

Jaime
...........................................................................
: domain: jds@mimsy.umd.edu				     James da Silva
: path:   uunet!mimsy!jds