[…] >>> >>>> The idea of register blocks is interesting. I wonder how that would >>>> translate in terms of access to invididual registers, i.e. does the >>>> block end up just being a prefix into the full register name, or is it >>>> something else? From your example declaration I picture that accesses >>>> would look something like `MMU_AS_CONTROL[4]::MEMATTR::read(bar)`, which >>>> ngl looks great, but I also cannot think of a construct that would allow >>>> such a syntax... Happy to think more about it though. >>> >>> Yes, that is the sort of syntax I was imagining, although I was hoping >>> you could do something like: >>> >>> let as = MMU_AS_CONTROL[as_id]::try_get(&bar)?; >>> >>> let memattr = as.MEMATTR.read(&bar); >>> memattr.set_attr0(3).write(&bar); >>> as.TRANSTAB.write(&bar, 0x1000); >>> >>> Which I'm sure shows how little Rust I've written, but hopefully you get >>> the idea - only the first line is a try_xxx which can fail and takes the >>> address space ID from a variable and bounds checks it. The other >>> accesses we already know the bounds so there's no need to deal with >>> failure, and we don't have to consider the situation where MEMATTR is >>> written but the TRANSTAB write fails (which couldn't actually happen >>> with non-contiguous register arrays but the compiler wouldn't be able to >>> tell). >> >> That for sure looks elegant. Now the question is how can we implement >> something similar using only ZSTs? `MMU_AS_CONTROL` would have to be a >> static array. Then `as` needs to be some sort of struct? >> >> The way this works looks very similar to what I suggested above with >> register arrays and validating once that a given index is valid for the >> register array accesses. Then the non-try accessors can be used, knowing >> that the compiler will be able to infer that the index is valid. The >> only drawback being that each `read` and `write` will have to carry the >> `as_id`. > > Presumably it should be possible to implement with 'as' being a type > which actually contains 'as_id' (as opposed to an actual ZST) so you > don't need to explicitly pass that in. Otherwise there's a possibility > of passing the wrong as_id in and so the compiler won't be able to infer > that it must be valid. > >> This would work, but if someone wants to experiment to try and implement >> something closer to the interface you proposed, I'm very open to the >> idea. I wonder if we could do this without any runtime overhead... > > Since my Rust knowledge is very limited there might be a better way of > doing this, but that this seemed like the most natural interface to me. > I can see how a similar approach could be used in C with minimal/no > overhead so I would have thought this is possible in Rust.
I hate macros with a passion, but I can try tackling this in the interest of moving it forward :) — Daniel
