Re: Arbitrary Sandbox

[Shark8 <onewingedshark@gmail.com>]

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.