[rescue] 128 bits...

[Jonathan C. Patschke]

On Fri, 7 Feb 2003, Lionel Peterson wrote:

> > And interesting problems.  I suspect you'd want object like that
> > aligned at certainly memory addresses (segments, if you will), sort
> > of like how IP networks are aligned at the all-zeros address of a
> > certain mask.
>
> I don't follow this, but it's probably just me...

Okay, if you have a network 10.1.10.0/24, you know it starts at
10.1.10.0 and runs through 10.1.100.255.  So, you can easily determine
network membership via a mask on the first 24 bits of the address.

If our networks started and ended on haphazrd boundaries (say,
10.0.10.37 through 10.0.11.12), you'd have to mark the beginning and end
of -each- network in some global lookup system, and describing networks
would be much more difficult because you couldn't say a.b.c.d/e.

Some memory systems use a similar technique.  For example, Intel x86
real-mode memory uses a segment and offset to determine memory
locations.  Each segment is 64k in length, and many kinds of data can't
spill between segments[0].  So, for example, if you know that you've
loaded some data into 1234:0000, you can look at the first part of the
address to determine whether or not you're looking at the right data.

> You would consume the address space in a linear fashion, not
> exponential they way I envision it...

Only if you wanted to be able to load differently-sized objects, and
then you're stuck the issues of fragmentation and additional accounting
(all of which has to be resolved on -each- access to a new object, and
each time the size of an object changes (possibly invalidating older
addresses).

If you wanted to make them all the same size (say, 4GB as the maximum
size), you can only have 4 billion such objects.  If you wanted them
bigger, the next size would be 8GB, leaving a maximum of 2 billion
objects.  100GB drives are around now, and with a 128GB memory partition
size, you're stuck with 256 million objects.

> You don;t solve real-world problems by using this type of storage
> arrangement, you solve programming/logical problems...

Funny, that's how discs work.  You don't have any real-world data on
your discs?

> > You could, I suppose, virtually map things at nice offsets, and
> > physically map them against a table (a la TLB), but you'd still have
> > to do a lot of song-and-dance behind the scenes.
>
> Naw, the OS would. ;^)

Well, -someone- has to write that OS, and that mapping still imposes a
runtime overhead.

[0] Which is why it's convenient (albeit wasteful) that adjacent
    segments overlap by 65520 bytes.

-- 
Jonathan Patschke  *)  "The clue phone is ringing, and it's for you."
Thorndale, TX      (*                                 --Dave McGuire