Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site daisy.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!nsc!daisy!david
From: david@daisy.UUCP (David Schachter)
Newsgroups: net.arch,net.micro.16k,net.micro.68k
Subject: Re: 24 bit vs. 32 bit address space
Message-ID: <83@daisy.UUCP>
Date: Thu, 7-Mar-85 05:40:06 EST
Article-I.D.: daisy.83
Posted: Thu Mar  7 05:40:06 1985
Date-Received: Tue, 12-Mar-85 07:46:52 EST
References: <983@watdcsu.UUCP> <2385@nsc.UUCP> <730@amdcad.UUCP> <2393@nsc.UUCP> <295@cmu-cs-spice.ARPA> <420@alberta.UUCP>
Reply-To: david@daisy.UUCP (David Schachter)
Organization: Daisy Systems Corp., Mountain View, Ca
Lines: 48
Xref: linus net.arch:747 net.micro.16k:232 net.micro.68k:577

In article <295@cmu-cs-spice.ARPA> skef@cmu-cs-spice.ARPA (Skef Wholey) writes:
>With a large address space, I should be able to allocate and deallocate stuff
>anywhere I want without penalty.  Sparse addressing lets me do that. I can
>have lots of tables grow very large without running into each other.  With
>a 32 bit address space, I should be able to have 16 tables that each have 256
>megabytes to grow in.  With a 24 bit address space, each table would have only
>one megabyte to grow in.  If just one of those tables becomes larger than
>that, then I'm screwed.

If you are writing prototype software, fine.  If you are writing commercial
software, you had better worry about tables running out of space, no matter
how big the address space.  Otherwise, you will be selling a program that
demos fine but breaks when customers give it input different than what you
expected.  (They always, always do, God bless 'em.)

The software I write has to run on a machine which usually has only two to
four megabytes of physical memory but a virtual address space of about a
gigabyte or so.  (It is an Intel 80286.)  My programs generally allocate
tables of a few kilobytes and then grow them as necessary.  That is, I keep
track of how many entries in a given table are used and how many are avail-
able.  When I have to add another entry to a full table, I allocate a bigger
chunk of memory, copy the original to the new chunk, delete the old chunk,
and fix up my various pointers, indices, and maxima.

Software that allocates fixed-size tables has limits.  Software that checks
for filled tables (or arrays or structures or whatever) and handles such cases
appropriately has fewer limits.  The size of the address space isn't an
issue.

(By the way, the 80286 has an address space of 16k objects per task of which
8k are global to the CPU and 8k are local to the task.  Each object can be
up to 64kB in size, an unfortunately small amount.  Objects can be protected
in a somewhat flexible way.  The number of tasks is unlimited.  Transfers
between tasks can be protected in several ways of varying complexity.  Objects
can be shared between tasks.  Parts of objects can be shared.  Shared objects
can have different access rights between tasks.  For example, an object might
be a code segment (therefore non-writable) to an application task but it could
be a data segment to the swapper task.  The 64kB limit on object size can be
hidden by compilers for a minor speed penalty.  Intel Fortran and Metaware
Pascal provide this hiding.  They will also generate faster code if the pro-
grammer provides assurance that the object is smaller than 64kB.)

("Intel" and "Metaware" are probably trademarks of the respective companies.)
[The opinions expressed in this article do not necessarily reflect the official
policy of Daisy Systems Corporation, its employees, or subsidiaries.  Opinions
expressed herein are the sole responsibility of the author, who is in the mar-
ket for a roommate to share a two-bedroom apartment in Mountain Views, CA (hint,
hint.)] {"Moscow in flames; missles headed towards London.  Film at eleven."}