So, like, the other day David Gibson mumbled:
>
> But you do take a hit w.r.t. *minimum* representation size - there's
> no form amongst all the possibilities here more compact than pure hex.
> Especially since spaces are optional in the old form. The fact that
> [ab cd 00] and [abcd00] are equivalent was a deliberate choice in the
> original form.
>
> The point of [] is for random binary data which is neither strings
> (even with the odd strange character) nor sensibly organized into
> 32-bit (or larger) integers. Wanting something other than hex here is
> much rarer than in the < > case.
>
> You're seeing < > and [ ] as basically the same thing - a list of
> values - with the only difference being the size of those values.
> That's not wrong, but it's not the only way to look at it - and it's
> not the way I was thinking of [ ] when I invented it. Your proposal
> makes perfect sense while you think of [] as a list of values - but
> not so much when it's thought of as a direct binary representation.
>
> So I'm thinking perhaps we need two different things here: a "list of
> values" representation, which can accomodate expressions and can also
> have multiple sizes (because expressions which are evaluated to a
> 16-bit or 64-bit value could also be useful under the right
> circumstances), and the [ ] "bytestring
> literal" representation. Perhaps something like:
>
> (32-bit values)
> <0xdeadbeef (1+1)>
> or <.32 0xdeadbeef (1+1)>
>
> (64-bit values)
> <.64 (0xdeadbeef << 32) (-1)>
> (8-bit values)
> <.8 0x00 0x0a 0xe4 0x2c 0x23 (0x10 + n)>
>
> i.e. < > is list of values form, with size of each value as a sort of
> parameter (defaulting to 32-bit, of course). I'm not sure I like that
> particular syntax, it's just the first thing I came up with to
> demonstrate the idea.
Ah ha! I see. You want this, then:
x = <.srec 0000 C001C0DEGE75BABE F1>
OK. That was entirely joking. We all know that
the cool code does NOT get the babe.
Seriously though, I see your point, and I don't really
have a strong opinion here, so in the interest of making
some headway, we can just leave it as is for now.
If it turns out to be a bad decision later, we'll fix it. :-)
And with that issue behind us....
I'm going to post these patches to introduce the new DTS format!
Any last straggler comments?
Thanks,
jdl
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
