More detail than I had intended on Layout description language

[Tobi Ajila]

>> 4. Unlike C bitfield numbering (which varies based on endianness of
target
>>    platform) we'll always number fields in little-endian order;
>>    that is, "byte a:1, b:7" (at address x) would be extracted with the
>>    expressions "loadByte(x) & 1" and "loadByte(x) >> 1", respectively.
>>    This is LE-centric, but has the nice property that bit 0 of a byte,
short,
>>    int, or long is extracted with the same operation (x & 1), and so on.

>This is the one place I am not sure.  I can argue either side of this, but
I think that
>the "ease of our code generation" is one of the lesser of several
dubiously compelling
>reasons.
...
>That's all I've got right now, I don't find it super-convincing either
way.

For now, let's stick with LE numbering since it is sufficient for common
cases.

> Container sizes are also powers-of-two.  I think there is a tension
between the maximum container
> size and memory-model issues.  I would like it to be the case that the
maximum container sizes
> corresponds to the largest number of bits that can be written atomically;
you would also like it to be
> the case that the minimum container size is the smallest thing that can
be updated without the possibility
> of reverting concurrent stores from other threads of execution.

We are not in favour of a max container size because we want container
sizes to be forward compatible with
future hardware. We can always revert to doing something slow (e.g. using a
lock) in order to achieve atomicity
in cases where containers are larger than the largest register size.

We must be able to describe misaligned containers because we must be able
to describe existing data
structures that have misaligned fields.  If we can describe misaligned
containers, we can also describe
odd sized containers (as long as they are a multiple of 8-bits). The
implementation will be able to
deal with both of these cases.

> Looking at your grammar, don't you need to be able to tag a container
with a non-default alignment?
>
> Or is it your intention that the algorithm is "default is natural
alignment if possible given supplied padding,
> otherwise the largest alignment that works with the padding, and ERROR if
any field within the container
> does not obtain its desired alignment?

My intention here is that the LDL spec only describes the size and location
of fields. Any alignment is specified
with explicit padding. We think the LDL spec should not enforce a container
alignment, but only represent it.

> I think the C assumption is that a uint64_t* is a pointer (on a
64-bit-ish machine) that is 64-bit aligned.
> If you want a pointer to a misaligned uint64_t, I think that is a
different animal (or do we take the
> position that we can hide that detail behind an interface?)

We want to be able to specify both of these:

on 64 bit:
struct Node {
     int8_t data;
     struct Node* next;
}

LDL:
Node, 128 {
    8 data,
    56 ,
    64 next,
}

struct __attribute__ ((__packed__)) Node {
    int8_t data;
    struct Node* next;
}
LDL:
Node, 72 {
    8 data,
    64 next,
}

With the use of locks, we can support structures with misaligned
containers.

> Think about structs containing structs, thinking about the generation
> of interior pointers/references, think about the need to know the
alignment of the pointed struct when a load
> is performed.
That's a good point

struct A {
    int32_t x;
    int32_t y;
}

LDL:
A, 32 { //default alignment of 32
    32 x,
    32 y,
}

struct __attribute__ ((__packed__)) B {
    int8_t z;
    struct A a;
}
LDL:

B, 72 {
    8 z,
    A a, //this is aligned to 8 not 32
}

Can I get 'a' and treat it like it's aligned? With the exception of atomics
this is not a big problem. Most
modern hardware allow you to access misaligned memory with some performance
penalties. The nested struct is
not the only case where this problem could occur. What if we point a
perfectly aligned Layout to an unaligned
memory location (like casting unaligned memory to a struct)?

We think there are 3 answers to this:
1) Ignore it - Use C behaviour as the standard
2) Don't allow it - Perform runtime checks for misaligned access and throw
an exception
3) Handle it safely - Provide two accessors, the regular one, and one that
can safely handled misaligned access

>> The 'atom' attribute ensures that an update to a field does not
overwrite other fields in the container.
>> A possible implementation could use CAS to do this.
>
> Is a compiler allowed to coalesce atomic operations within a container
into a single CAS?
Yes, I don't see a reason not to allow this.