add +: slices #1316
add +: slices #1316
Conversation
ChrisDodd
force-pushed
the
cdodd-slice
branch
from
554c061 to
229b98a
Compare
|
I'm unclear whether these changes need to be also in the asciidoc version, or if that happens automatically. Or perhaps we should wait until after the switchover to asciidoc and do it only there. |
|
I think it is worth discussing at the next LDWG meeting, exactly when Madoko -> AsciiDoc conversion happens. Fortunately, for text paragraphs with little or no markup, it usually makes no difference. That said, the changes are so extensive for Madoko->AsciiDoc that I expect if that change is made before this PR, some small changes may be required in this PR. I think small changes to a PR like this to update it will not be wasted effort. |
p4-16/spec/P4-16-spec.mdk
Outdated
| @@ -3489,6 +3489,11 @@ Bit-strings also support the following operations: | |||
| The effect of this statement is to set bits `H` through `L` (inclusive of | |||
| both) of `e` to the bit-pattern represented by `x`, and leaves all other bits | |||
| of `e` unchanged. A slice of an unsigned integer is an unsigned integer. | |||
| A slice may also be specified as `[L+:W]` where L is the lowest bit of the slice | |||
| and W is the width of the slice. In this case, only W must be a non-negative | |||
| local compile-time known numeric value. L must also be a numeric value and | |||
There was a problem hiding this comment.
Please add markup to this occurrence of L, i.e. L with backticks
There was a problem hiding this comment.
Also for the earlier occurrence of W in the paragraph.
There was a problem hiding this comment.
Is this form of bit-slicing expected to work for values of type int<W>, too? If so, it might need to be mentioned explicitly in the section on operations on type int<W>. It seems to me reasonable to refer to the explanation in the section on bit<W> operations rather than copying and pasting, but also good to mention that the result is always of type bit<W>, which I think is what is specified for [hi:lo] bit slices on type int<W>.
There was a problem hiding this comment.
The int<W> description was just a copy of the whole paragraph from here, so I shortened that to just refer to the bitstring description.
p4-16/spec/P4-16-spec.mdk
Outdated
| local compile-time known numeric value. L must also be a numeric value and | ||
| some architectures may require it to be compile-time known. Some architectures | ||
| may allow variable indexing. |
There was a problem hiding this comment.
This wording currently allows L to be negative (e.g. either negative int literal, or int<N> expression which can have a negative value). A way out would be to say that its type must be either int, in which cast it must be non-negative, or bit<N>-expression. I think it would make sense to restrict this, as slices on negative bit index don't make sense.
There was a problem hiding this comment.
Yes, this is tricky. I added some verbiage to require non-negative in-range values, but only require an error message for constants, as it may be tricky to do that for variable values, and we don't have any way of dealing with it at runtime.
Signed-off-by: Chris Dodd <[email protected]>
ChrisDodd
force-pushed
the
cdodd-slice
branch
from
229b98a to
9e2601b
Compare
|
@ChrisDodd Sorry for the inconvenience, but we have, after several months of planning, transitioned the P4 language specification source from Madoko to AsciiDoc. Thus most or all of your PRs will need to be updated so that they apply to that version. Hopefully this should be fairly straightforward, e.g. by looking at examples of how things like section headings, bullet items, etc. are marked up in the latest version of the file P4-16-spec.adoc If you have questions on how to change things for AsciiDoc, feel free to ask. Note that creating a new PR with similar changes as this PR might be easier than updating this PR. |
No description provided.