On Mon, Jul 15, 2013 at 2:30 PM, Sandro Magi <[email protected]> wrote:
> On 15/07/2013 5:25 PM, Jonathan S. Shapiro wrote: > > The only case where this arose in BitC was unboxed unions containing > > references, and Eric Northup identified a layout approach for those > > that CLR would recognize as safe. > > Is this documented somewhere? I don't think so, but the idea is simple. BitC didn't actually come out and require that specified field order be preserved by the compiler. The *intent * was that field order handling would be specified in a platform-specific profile/addendum. Partly because you want to be able to match the layout behavior of the native ABI. As a naive example, if you see a struct having fields of char, ulong, and char in sequence, it makes sense to move the second character forward to eliminate the blank space in the packing. There exist ABIs in which this rearrangement would be routine. Given the loophole in the specification, you could imagine a platform-specific addendum for CLR in which the specification of union layout for unions with references operates as follows: First, remove all fields of reference type from all legs of the union. Note that the remaining union is reference-free, and can be handled with explicit field positioning without loss of safety (which is how value-typed unions are handled in any case). Now append the reference fields to the result in non-overlapping form, such that each leg of the representation structure contains storage for every possible reference field. Because those fields do not overlap, the runtime can see that the data structure is safe. The end result is that you do not get the *compression* of an unboxed union when reference types are present, but you *do* get the *semantics* of an unboxed union. And the naive copy semantics implemented by the core of CLR works fine. You could do better where you happen to notice that two disjoint fields happen to share the same type, but that's a space optimization. Oh. And note that *boxed* unions can be realized with a CLR class hierarchy, so there is no problem in this case. It's not pretty, but it's good enough to get a version of the language up and running quickly, and it actually isn't as awful as it sounds in practice (because unboxed unions rarely contain reference fields). Jonathan
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
