Useful to create different bit slice variant that makes bit width easier to determine if it is compile time known?

[jafingerhut]

This is not a high-priority proposal. I thought of it while thinking about comments from Chris Dodd on examples of P4 loops that attempted to use bit slice expressions with the loop variable in the expressions for the most and/or least significant bit positions of the slice, and realizing that even if it is easy for a person to determine that a bit slice has a bit width result that is a compile-time known value, it might be complex for the compiler to infer that.

I like backwards-compatible additions to a language. If this proposal goes forward, there would be no reason I can see to either deprecate, nor give any hint of a plan to remove the current bit slice syntax. The current one and the new one both seem useful to me.

With today's bit slice syntax, if the following is legal (i.e. both low and hi ends of bit slice are within the bounds of the type of variable val), and if evaluating <arbitrary_expr> has no side effects, then it is easy for a human to see that the type of the result must be bit<3>:

val[<arbitrary_expr>+2:<arbitrary_expr>]

However, for the compiler to reach the same conclusion, it requires some potentially onerous checks to be performed:

• <arbitrary_expr> has no side effects that cause its value to change on repeated evaluation
• <arbitrary_expr> is the same in the two occurrences of the expression. That can be complicated by questions of whether different arithmetic expression syntax that can be proven to evaluate to the same value should be determined by the compiler to be always equal, or if it should give up if the expressions have different ASTs.

This issue raises the question of the possibility of introducing a new expression for bit slices.

I do not have good proposed syntax yet, but for the sake of example I will use the syntax val[<lsb>,<bitwidth>], with a comma separating the values instead of a colon.

• val[L,W] is equivalent in meaning to val[L+W-1:L], except that the expression L is guaranteed to be evaluated exactly once (or at least, any side effects it has are guaranteed to occur exactly once). It has all of the same range requirements on the values of L and W that val[L+W-1:L] has upon the values of L+W-1 and L.
• If W is a local compile-time known value, then the compiler is guaranteed to be able to infer that the type of val[L,W] is type bit<W>.

[jafingerhut]

@ChrisDodd This is certainly not urgent, and may not go anywhere, but curious if you get a chance to read this and provide any feedback you have.

[jafingerhut]

Related issue (and perhaps should supercede this one): #1304

(but if we close this one, good to add to that one the desired behavior that if the bit width of the slice is a compile-time known value, then the compiler should be able to type check it): #1304

[ChrisDodd]

I missed this one when you first created it, but yes, the proposal in #1304 is essentially the same issue. I find it interesting that Verilog, faced with essentially the same problem (fully general non-constant slices are too expensive and non-analyzable), came up with a syntactic solution. I do think using Verilog's syntax rather than inventing something new would be better.

[jafingerhut]

Closing this issue in favor of the similar #1304.