Put padding for cluster-arrays inside each individual array element,

[rcls]

Currently, some SVD arrays get emitted as a sequence of numbered fields, instead of as a single rust array, due to padding between elements.

This change moves the padding into the array elements, allowing the SVD array to be emitted as a rust array. This makes the generated API more consistent and easier to use. (The downside is that the API changes are not backward compatible.)

Cypress PSOC and Traveo processors appear to be particularly effected with this, it looks like many others get no change. I made a git repo show the changes for three processors at rcls/svd2rust-example@08798fc

[rust-highfive]

r? @burrbull

(rust-highfive has picked a reviewer for you, use r? to override)

[burrbull]

This is excellent change in theory.
But do you check than those reserved spaces don't cross with other registers?
if dim_increment != addressOffset it is not guaranteed that spaces are empty.

[rcls]

I hadn't thought of the case where some random other register was placed within the padding (Does SVD allow that? - I'm not particularly familiar with the specification).
Yes, now you point that out, I'm pretty certain I could concoct a SVD that would break with this change. I have no idea whether or not it is a real-life problem. (Also I suspect you could produce similar nastiness that would break svd2rust as it is today.)

[burrbull]

Does SVD allow

I'm afraid, the answer YES.
I saw many such files.

[rcls]

I saw many such files.

I'll attempt to address this & only apply my change in cases where it is safe. Do you have a SVD you can point me at? (Or I can probably make one up).

[rcls]

To get this right, seems to need a bit of re-arranging of the existing code, as currently we decide whether or not to split an array before sorting, making it harder to know whether or not another register falls into the padding.
And potentially the array could be nested inside another cluster, with a potentially conflicting register outside of that containing cluster. Apart from needing to find that register, we also need to deal with the fact items in different clusters have different base addresses, so the offsets can't be directly compared...
So I'm thinking:

• Expand to Vec<RegisterBlockField> optimistically assuming that SVD arrays can be kept as arrays.
• Then have a separate pass on the Vec<RegisterBlockField> expanding arrays when necessary.
• We also need to consider arrays with names in dimIndex, if we defer expanding those then we need to push the dimIndex into the RegisterBlockField, which seems a bit ugly. Instead, I think factor out the array-expansion code so it can be called separately to cover this case also.

@burrbull does that sound like a sensible plan to you? Or am I still missing some complexity.

[burrbull]

I'm thinking about 2-pass expanding of peripheral children.
On first pass we need to get memory map of peripheral.
It might look like Vec<u8> where u8 is number of different registers mapped on corresponding byte of peripheral.
Size of vector is number of bytes in peripheral.
On second pass we can see if register/cluster intersects with any other just by looking on memory map.
This is just an idea.

[rcls]

A much less elegant solution, but easier to implement, would be to add methods to do the array indexing on the containing cluster: get_foo(self,idx:usize)->&FOO
That can just do address arithmetic internally.
One advantage of this, is that it can co-exist with cluster arrays with named elements.

[burrbull]

A much less elegant solution, but easier to implement, would be to add methods to do the array indexing on the containing cluster: get_foo(self,idx:usize)->&FOO
That can just do address arithmetic internally.
One advantage of this, is that it can co-exist with cluster arrays with named elements.

This is a good temporary solution in the sense that we can deprecate it some time after we find better way and implement it.

[rcls]

A slight variant on the get_foo() idea: create a zero-sized-type implementing the Index trait to do the address calculations. As long as safe code cannot create objects of that type, it is just more convenient syntax for the same thing.
It seems pretty straightforward to code...

[rcls]

Closing this pull-request. #534 has a different approach which doesn't fall foul of the problems discussed above.