encoding of prefetches impose minimum sensible granularity of cache blocks

[jnk0le]

as of 0.6 draft:

Prefetches are encoded in ori HINT space so the offset[4:0] at bits [11:7] is unusable as rd must always be zero.

offset[11:5] provides only 32 byte granularity. In case of 16 or 8 byte blocks, there will be gaps inaccessible by offset. Redoing S-type to I-type imm allows to take one or more bits for narrowing that gap at the cost of encoding space (the bottom of the offset will be discarded anyway)

[dkruckemyer-ventana]

This is a bit of an encoding illusion: one may see an S-type encoding with rs2 used as "function" bits, or one may see an I-type encoding where rd must be 0 and imm[4:0] are "function" bits. It's really both. The duality arises because an instruction decoder wants to see the I-type encoding to decode as a HINT and the address generation unit wants to see an S-type encoding to calculate the immediate without requiring a new immediate computation.

Ultimately, there's a tradeoff between available HINT space and the granularity of the immediate (plus there needs to be room to grow to add additional "function" information to the prefetch instruction). Given the limited available HINT encodings and the expectation that most implementations have 32B cache blocks or larger, we opted to compromise on the granularity of the immediate.

[jnk0le]

Since those are HINTs, I think that offset[4:0] should be removed from their documentation. (can be substituted with something like rd=x0)

[aswaterman]

IMO, the current formulation is preferable. If we were to change, we'd have to add a sentence to the normative text that "offset[4:0] is 0". As it stands, the instruction encoding diagram states this fact quite concisely.

[dkruckemyer-ventana]

Closing since I believe this issue has been addressed.