Is a packed array the same or close enough to a std vector? Should we just re-use that?
Oh yeah, good point, it might make sense to put unpacked array in the SV dialect. The two should still compose together in either case.
@jdd a std.vector type is a semantically different thing.
Yeah, that was my original thought as well. I also see how one could consider an operation on a packed SystemVerilog array to be a SIMD operation of sorts.
Anyway, I agree that it should be a different type.
I’m not sure how much of the packed/unpacked distinction in SV we should inherit.
I always had the feeling that the distinction in SV itself is fairly artificial and more geared towards guiding SV’s horrendous implicit casts to bit vectors, and optimizations for simulations (what can be collapsed into a single-driver bit array – packed, and what needs separate tracking unpacked).
As @jdd points out, I’m pretty sure we don’t need these in the RTL dialect, as they make for a weird duplication of the type system and a lot of the logic for the unpacked/packed structs/arrays, and would invite subtle semantic differences to be introduce between the two.
Maybe we could have an attribute of sorts that indicates to the SV dialect if something should be an unpacked array? Or there might be actually some reasonable logic to automatically determine if something should be packed or unpacked.
Why not just have rtl.array<T, n> and sv.unpackedarray<T, n>? This allows directly modeling what we’re looking for here and keeps the icky bits in the SV domain.
1 Like
@clattner Yeah that looks like a great approach! I have a feeling that most of the LLHD types can eventually be replaced with the RTL types we’ll settle on. Less redundancy 
!
2 Likes