Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!mtxinu!unisoft!hoptoad!peora!rtmvax!bilver!wbeebe
From: wbeebe@bilver.UUCP (bill beebe)
Newsgroups: comp.os.minix
Subject: Re: PC Minix/64KB limit
Message-ID: <412@bilver.UUCP>
Date: 18 Feb 89 05:03:20 GMT
References: <415@lzaz.ATT.COM> <2485@sun.soe.clarkson.edu> <417@lzaz.ATT.COM>
Reply-To: wbeebe@bilver.UUCP (bill beebe)
Organization: W. J. Vermillion, Winter Park, FL
Lines: 61

In article <417@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes:
>1. the 8088, 8086,80186, 80286 totally lack the ability to address beyond 64KB.
>   There simply is no such machine operation.  Microsoft added the ability
>   to there C compiler output by adding 'far' pointers that basically pull
>   2 16 bit addresses from memory (segment:offset) and access one byte/word
>   with the effective address.  Slow, Clumsey, but the only way to do it.

 The "problem" with the 80x86 family is a little more subtle than that. The
so-called 64K limit has to do with the segment limit size. When you say
the 80x86 family "totaly lacks the ablity to address beyond 64KB", you
neglect to mention that the 64K window can be placed on any 16 byte boundary
(called a page) within the 1 meg real address space. It is a very simple
matter to re-load a segment register and point anywhere. Furthermore, there
is an automatic way for code greater than 64K to execute without explicite
segment manipulation. Using far calls allows code in one seperate 64K code
segment to execute code in another. You can use the other segments, the
DS (data segment), ES (extra segment), and SS (stack segment) to address
three seperate 64K data segments for a total of 192K of data. In fact, it's
nice to have the stack segment totally seperate from the current code and
other data segments to avoid corruption due to stack overflow or underflow.
As far as far pointers are concerned, it was Intel who provided the example
in their original development tools, PL/M and ASM. Far pointers are slow
and clumsy only if data is scattered all over the place. If data are
reasonably grouped, but in different areas > 64K apart, then the base
segment of one area can be loaded into DS with the other in ES. You then
use segment overides to move data between the two areas. One more thing;
the 80286 addresses 16 meg in protected mode, with the same 64K segment
limit. It's different, but not ugly.

>3. Extened (or is it expanded) memory uses a window in the address space of
>   the machine to access more memory.  This is the only scheme on the
>   8088/8086. While useful for data bases, and other dedicated programs it
>   a real mess for loading programs into.

 Extended memory is memory above 1 meg, available only to 80286 and 80386
based machines. Expanded memory is memory banked into an unused segment
in a real address space. That segment is usually $D000:0000.  You're
correct that it is the only scheme on the 8088/86. However, you can have
data and executable code in LIM data space. This is supported in LIM 4.0
drivers and hardware. Furthermore, if you reduce the base memory from
640K to 256K, LIM 4.0 can support swapping LIM memory from the 256K
on up. In other words, operating systems that know about LIM can swap
multiple 64K pages from the 256K address limit to the 640K limit into
and out of the expanded memory pool. Examples of programs that can
now do this is DoubleDos 5.0 and Windows v2.1. Limited multitasking is
possible with this method.

>   when running in protected mode.  This paging mode was invented by someone
>   who hated programmers.  Its use in MINIX will take much patience!

Protected mode was not invented by sadistic design engineers bent on
enslaving honest hardworking programmers in segmentation hell. Your comment
is indicative of a lack of personal experience and is to be expected from
someone mouthing the opinions of others.

>Howard C. Johnson
>ATT Bell Labs
>att!lzaz!hcj
>hcj@lzaz.att.com

I can't belive this really originated from Bell Labs. *sigh*