On Mon, Mar 2, 2015 at 2:24 AM, Keean Schupke <[email protected]> wrote: > > > On 2 March 2015 at 08:57, Matt Rice <[email protected]> wrote: >> >> On Mon, Mar 2, 2015 at 12:34 AM, Keean Schupke <[email protected]> wrote: >> > Yes I think it can be done using tuple types and tagged unions and I >> > posted >> > an example. >> > >> > All it relied on was consistent memory layout for records and tagged >> > unions. >> > >> > You just have a record that has the common data in a header section, and >> > the >> > tagged union of records in a body section. There's a reason its called >> > an >> > 'object header' right? >> >> I think where we differ here is subtle in that a tagged union can only >> support a single type in this mechanism, and a RW key in the header, >> and a RO key in the header can trigger the RW key to have both read >> and write types, and you are saying that they must be represented by >> different types in the tagged union, one which subsumes the other. > > > I am not sure I understand the details of this. Types don't restrict machine > code access to data, so the kernel must marshall all read/write requests to > this region (IE must be in kernel not user address space). You might need to > go into a bit greater detail.
I was really just using it as an example since it is an easy understand one where the difference of a bit in the type tag causes causes write functions to be associated with the read-write type (in how the kernel (or some thing) differentiates a read-only cap from a read-write one) that is IIUC the whole 'derivation' sequences in [1] are based on multiple interpretations of a type tag, more so than being of a single type implementing the functions of its parent type. so the dispatch is based on a masking out bits from the type. http://coyotos.org/docs/base/interfaces.html _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
