[foreign] RFR 8218153: Read/Write of Value layout should honor declared endianness

[Maurizio Cimadamore]

On 03/02/2019 20:16, John Rose wrote:
> On Feb 3, 2019, at 12:04 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> …
>> I quite like this because it has a nice correspondence between layout API and description: in both cases there's no explicit support for NE - which is encoded always as a lack of explicit endianness info.
> Well, I like it too.  Thanks for teasing out the details.

Thinking more about it, I found one thing that this approach would kind 
of preclude to us. We have talked in the past about the possibility of 
having 'portable' layouts that can be referenced 'by name', using the 
unresolved layout machinery  - e.g.:

 >i32(C_int)

So that, if code wants to use a C int, it can refer to the magic layout 
by name and the right thing will happen.

Now, with the rules I proposed, this approach would fail; for instance 
if you defined a function descriptor like this:

getpid=()${C_int}

This will be an error, because this descriptor will be rewritten as:

getpid=()>i32

And, as per the rules I described, it is an error if arguments/return 
layout mention endianness-ful layouts.

I don't see any great way out of this problem - other than making the 
layout substitution a context-sensitive operation: replacing a layout 
expression with a concrete layout has different semantics depending on 
whether the replacement happens inside a function or not. If the 
replacement happens inside a function, the resolution machinery will 
take care of 'stripping' endianness of the replaced layout.

This is doable of course, but it's more complexity (both in impl and in 
terms of user model) - are we ok with it?

Cheers
Maurizio

>
> One other advantage:  The NE state can naturally be upgraded
> after the fact to BE or LE (or vm-specific PE of course).  This means
> that we have more options for layout strings produced by jextract
> or by hand:  They can be conveniently left in the NE state, and
> the BE or LE state can be pushed into the layout string from context.
>
> This gets an effect very similar to what Henry wants, which is a
> sensible default for simple notation.  It gets this effect not by
> eagerly assigning PE to elements in a layout string (which I
> don't want) but rather allowing a chance for the context of the
> layout string to supply then needed polarity.  The polarity
> can be explicit in a central place, such as in a global argument
> sent from jextract to the binder.  For casual use with PE, the
> polarity can be quietly injected as an optional argument to the
> function which parses layouts.
>
> The basic idea behind this, of NE, is that some layouts can
> (and should) be "endian pure" in refusing to take a side, and the
> endian-ness can be specified where it is needed, in order to
> form correct memory accesses.
>
> Thanks, guys.
>
> — John
>
>