restrict YBNDSWI to 8-bits (anticipating a smaller immediate following ARC review)

[tariqkurd-repo]

We don't have any compelling data for the top 2 bits of the 10-bit immediate, so instead of waiting for it to be rejected by ARC we may as well trim it up-front.
The 8-bit immediate covers all the CHERIoT use cases, and almost all of the FreeBSD use cases too.

[nwf]

A) We'd already pretty severely restricted YBNDSWI: for the I-type format we'd taken, we had also required that rs1 = rd and imm[11:10] = 0.

B) If you're going to restrict to 8 bits worth of immediate, almost surely "1 through 256" is not the best choice.

C) This doesn't change that we're still expanding into a whole new I-type-shaped chunk of the encoding space (opcode=0011011, funct3=011), so... why?

[tariqkurd-repo]

I've changed the calculation to avoid the adder, but the point is that quadrant 0 (imm[9:8]=0) represents the values 1 to 256, now and before.
This gave the following coverage - we can't justify adding 2 more bits for ~2% more fro CHERIoT or ~4% more for FreeBSD.
I don't know if they'll go for the rd==rs1 idea.....
Encoding space is extremely limited, so I'm trying to smooth the process of getting this through.
This means they can use the upper bits as part of the opcode for more immediate based encodings.

[nwf]

This seems like speculative spec churn without concrete feedback from ARC. Can we please just wait?

If they somehow go for the very specific position of giving us an I-type whose immediate (and/or rs1) we can carve up sort like this, but for some reason a 10-bit slice of that I-type is too much but an 8-bit slice is OK, I'd suggest redoing the survey with this formula: ((imm[5:0] + 65) << imm[7:6]) - 64

[tariqkurd-repo]

We can wait - I'l mark this as draft.
My observation is that > 95% of all cases are covered by quadrant 0 (> 98% for the cheriot use cases), so simply keeping quadrant 0 is where we will end up.
They'll ask for the data and that's what it shows.
Redoing the data for another formula is certainly possible, but I think it's unlikely to give a better result.
Unless you have more data to add of course.

The spreadsheet is here: https://codasipazure-my.sharepoint.com/:x:/r/personal/tariq_kurd_codasip_com/Documents/CSetBounds%20immediates%20in%20FreeBSD.xlsx?d=w065e4286b1044a5da28421eb2c659e34&csf=1&web=1&e=RWHkmo

[nwf]

None of my MS hats have access to that URL.

For CHERIoT, at least, the data you've shown suggests that there was no gain in moving from 7 to 8 bits, and since there is gain to be had in moving from 8 to 9 bits, that suggests that a formula with further reach (be that ((imm[5:0] + 65) << imm[7:6]) - 64 or ((imm[6:0] + 129) << imm[7]) - 128 or something else) will be a win.

[arichardson]

I think we should just wait and see what ARC decides on the opcode allocation.