From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,af0c6ea85f3ed92d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.189.197 with SMTP id gk5mr3707487pbc.1.1331168575535; Wed, 07 Mar 2012 17:02:55 -0800 (PST) Path: h9ni51637pbe.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Arbitrary Sandbox Date: Wed, 7 Mar 2012 17:01:26 -0800 (PST) Organization: http://groups.google.com Message-ID: <31770251.29.1331168486951.JavaMail.geo-discussion-forums@ynbo9> References: NNTP-Posting-Host: 24.230.151.194 Mime-Version: 1.0 X-Trace: posting.google.com 1331168575 14592 127.0.0.1 (8 Mar 2012 01:02:55 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 8 Mar 2012 01:02:55 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=24.230.151.194; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Date: 2012-03-07T17:01:26-08:00 List-Id: On Wednesday, March 7, 2012 1:32:52 PM UTC-6, tmo...@acm.org wrote: > > But there's an inherent inefficiency in segmentation: the size of > > all your pointers doubles. Or to look at it the other way around, > > for any given amount of address space, it's split inconveniently. > > With the amount of memory I can afford today, a 32-bit segment > > number plus a 32-bit offset wouldn't be enough (both too few > > segments and segment size too small). 64-bit seg num plus > > 64-bit offset? OK, big enough, but inefficient. 64-bit flat > > address space: perfect! ;-) > > How many programs have more than 2**16 different objects? You could use > 16 bit segment numbers and 48 bit offsets to give you 64 bit pointers. > That's 64K distinct segments, each of 256 terabytes. A flat 64 bit > address is going to have the upper quarter (at least) of bits zero anyway > on most machines for some years to come. > Big addresses take a lot of storage if you have large arrays of full > pointers (not just offsets). But segments shrink *code* size by > occasionally loading segment registers, but usually using a small number > of bits to indicate which segment register to use in an operation. > Segments are like using people's first names, or even pronouns, instead > of full names all the time. You can't run a company-wide database on > first names, but in most discourse you would say something like > "Does Bob want coffee too?", not "Does Robert A Duff want coffee too?". You know, I thought that the 16-bit segment / 48-bit offset sounded good several years ago... when 64-bit processes were coming into vogue/hype; given that each additional bit doubles the addressable memory.