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."}