[prev in list] [next in list] [prev in thread] [next in thread] 

List:       eros-arch
Subject:    composed things
From:       Bryan Ford baford () schirf ! cs ! utah ! edu
Date:       1994-12-08 18:33:49
[Download RAW message or body]

I'm forwarding this to the list, because I think this may be an issue
that's not yet fully clear or agreed-upon in general.  Hope you don't mind.
I'll present my version of the answer; Jonathan can point out any differences
with his ideas.

>I'm not clear on the difference between "composed memory objects" and
>"composed mappings". Could you explain? Please try to be very clear and
>explicit about the differences, since we come from different backgrounds
>and have different paradigms.

A memory object fundamentally represents _data_ - something that can
be read or written directly, or mapped into memory and read indirectly
through processor load/store instructions.  A memory object is very
closely analogous to a Unix file handle, representing an open file.

A composed memory object is a memory object built from other memory
objects, presumably with the data it "presents" manipulated in some way
with respect to the memory objects from which it is composed.
The simplest example is creating a memory object that looks like
a concatenation of two other memory objects, one after the other;
that's the example Jonathan showed with his pretty ASCII picture. :-)
Another example would be a memory object that represents the uncompressed
version of an underlying compressed data stream: the "composition layer"
is responsible for compressing and uncompressing data as it passes back
and forth through the layers.  The basic idea of composed memory objects
doesn't necessarily imply any particular consistency model, or whether
or not the "underlying" memory objects can also be accessed in ways
other than through the composed memory object.  The common thread,
however, is that memory objects fundamentally represent _data_, and
don't really care exactly how that data is accessed (memory mapping
versus direct read/write or whatever).

A composed _mapping_, on the other hand, implies mapped memory.
To make use of a composed mapping, you have to insert it into your
protection domain - direct read/write access doesn't really make sense.
Mappings typically imply pre-assigned memory addresses: if you
insert a mapping into your protection domain, it's the mapping object
that determines at what address the data appears, not you.
Assuming you've solved the conflict/overlap problem, this means
that everybody who uses a mapping will see the same data at the
same place, which means that they can share arbitrary data structures
containing pointers or whatever.  Also, unlike a [composed] memory
object, which is typically densely populated (e.g. a file contains
data from offset 0 to offset size-1), a composed mapping object is
likely to be composed of sparce sub-mappings from "all over" the
address space: a little strip of memory mapped here, a little there, etc.

Does this clear up the issue a little?  Jonathan, do you agree?

				Bryan

[prev in list] [next in list] [prev in thread] [next in thread]