On Wed, May 15, 2019 at 09:15:20AM +0100, Andrew Jones wrote:
> On Tue, May 14, 2019 at 03:32:13PM +0200, Markus Armbruster wrote:
> > Syntax that can support such growth would be nice.
> >
> > To grow a single unsigned number, we can make it wider (but we don't
> > have infrastructure for numbers wider than 64 bits), or we can add more
> > numbers (but under what name?).
> >
> > Dotted keys syntax could grow more easily, but it's rather awkward.
> >
> > Looking more closely at your "[PATCH 11/13] target/arm/cpu64: max cpu:
> > Introduce sve-vls-map"... your syntax reflects your data structure:
> > property "sve-vls-map" is of type uint64_t, and interpreted as bit set.
> > This data type would have to grow, too.
> >
> > We could make widen the integer property (but we don't have
> > infrastructure for integer properties wider than 64 bits), or we can
> > turn it into an array of integers (compatibility?), or we can add more
> > properties to hold the additional integers (yet another silly way to
> > represent a list/array of integers).
> >
> > I'm not asking you to complicate things just to future-proof this. Just
> > pause and think whether you can pick a data type that's similarly
> > convenient now, and easier to grow.
> >
> > Then pick an external syntax for this data type. You may have to pick a
> > reasonable compromise between ease of implementation and ease of use.
>
> Widening the integer property sounds good to me. I just hadn't thought of
> it (implementation tunnel vision affecting my user interface design).
> Andrea also mentioned that as a possibility in a reply to the series. I
> think we can leave the property as a uint64_t right now and then, when/if
> it needs to expand past 64 bits we can change the property to a string
> and start parsing arbitrarily large integers from it. The internal state,
> 'uint64_t sve_vls_map' can easily be changed to a 'uint64_t sve_vls_map[]'
> at that point too. How's that sound?
Having an arbitrary-width integer should work.
It will suck a bit for the common case of sparse vector length support
0x8000000000000000800000008000808b
(= [ 1, 2, 4, 8, 16, 32, 64, 128 ] quadwords)
Since lengths above 16 quadwords remain theoretical for now though it's
probably OK as a compromise, though.
The most human-compatible approach would be some kind of list
comprehension syntax, but it's hard to justify that adding a whole new
syntax is justified at this point.
[...]
Cheers
---Dave
