Re: Arbitrary Sandbox

[tmoran@acm.org]

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