Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!osu-cis!att!cbnewsl!mjs
From: mjs@cbnewsl.ATT.COM (michael.j.scheutzow)
Newsgroups: comp.os.minix
Subject: ibm process size
Message-ID: <134@cbnewsl.ATT.COM>
Date: 17 Feb 89 22:05:28 GMT
Organization: AT&T Bell Laboratories
Lines: 38

>  the 8088, 8086,80186, 80286 totally lack the ability to address beyond 64KB.
>  There simply is no such machine operation.

This is extremely misleading.  The Intel architecture uses "segments", and
although each segment is limited to 64Kb, a single program can have as many as
it wants.  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.

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.

>  the .exe format allows for text, data, or both to exceed 64K, by finishing
>  the relocation to physical address when the program is loaded.  This is
>  the same idea as the ATARI ST uses when it loads.

Text and data can only exceed 64K if they are in multiple segments.  The
segment addresses are assigned at load time; it's unlikely to be the same
approach used by a M680x0 machine.

> The bottom line is that:
> A. ...
> B. A program can exceed 64 K only by using the Microsoft extensions.
>    A MINIX would need to create Microsoft C 5.1 to have a CC command.

Obviously untrue.

Cheers,
Mike S.
att!cbnewsl!mjs