jafingerhut
commented
1 year ago Rationale for introducing this feature: There are some who would like to use long lists of entries or const entries within a P4 program, with a repetitive structure to some of those entries.
Of course it is possible to write a simple program in a general purpose programming language such as C++, Java, Go, Python, etc. that prints out a list of the desired entries, and #include that into a P4 program. The proposers of this feature know this, and yet would still prefer if it were possible to do something like the following straw-man-syntax example proposes:
action my_drop() {
mark_to_drop(stdmeta);
}
action set_port(bit<9> port) {
stdmeta.egress_spec = port;
}
table ing_filter {
key = {
stdmeta.ingress_port : ternary;
hdr.ipv4.ttl : ternary;
hdr.ipv4.protocol : ternary;
}
actions = {
my_drop;
set_port;
NoAction;
}
entries = {
(_, 0, _): set_port(CPU_PORT);
#ifdef NEW_FEATURE
for (p in (list<bit<8>>) {3, 18, 19, 28, 42, 52}) {
// Note: Within a for loop body, the loop variable is
// a local compile-time known value.
(_, _, p) : my_drop();
// There can be additional entries here, and all of
// them within the { } of the for loop are generated
// once per loop iteration.
}
for (bit<8> p = 128; p <= 255; p = p + 1) {
for (bit<9> port = 0; port <= MAX_PORT_ID; port = port + 1) {
(port, _, p) : my_drop();
}
}
for (bit<8> p = 80; p <= 120; p = p + 1) {
if (p != 99) {
(_, _, p) : my_drop();
}
}
#endif // NEW_FEATURE
}
const default_action = NoAction();
}Complete P4 program can be found here: https://github.com/jafingerhut/p4-guide/blob/master/table-entries-with-for-loops/example1.p4
2023-Aug-02 update: From discussion later in this issue, I would like to focus on only two use cases for bounded loops in P4 at this time:
forloop context (a) - insideentriestable property
This only to make sense to me for such a loop to be implemented via compile-time evaluation of the loop and/or if statements to produce a finite set of entries.
Inside the body of a loop in context (a), all occurrences of the loop variable identifier are treated as local compile-time known values, equal to the value that the loop variable takes during that iteration of the loop. The only things that can be within such a for loop are: nested for loops, if statements, or table entries.
forloop context (b) - inside theapplyblock within acontrol, inside of anactionbody, or inside astatedefinition within aparser
Loops in context (b) could be implemented either by compile-time unrolling of the bounded loop, or some targets could implement them at run-time in a way similar to how a general purpose CPU often does so -- the resulting behavior would be the same regardless of the implementation.
Inside the body of a loop in context (b), all occurrences of loop variable identifiers that are newly introduced by the loop are "read only" values, i.e. they are treated similarly to a direction in parameter, so it is a compile-time error to attempt to modify its value in any way.
Any statement that can appear where a context (b) for loop appears, may also appear within the body of such a for loop, e.g. if the for loop appears within the apply block of a control, you can apply tables, apply sub-controls, call actions or extern functions, have if or switch statements, execute return or exit statements (which cause the for loop to be exited early), have nested for loops, etc.
(This is the end of text specific to for loop context (b)).
I propose that only for loops are defined, not while, repeat ... until, or do ... while as they appear in some other imperative languages, because for seem easier to specify and write in a way that a compiler can verify the number of iterations is bounded at compile time. If someone has proposed implementation mechanisms to determine that other forms of loops are compile-time bounded in their number of iterations, we can consider those, too.
I also propose that we either:
- do not introduce
continueorbreakstatements at this time, or - discuss exactly how to implement these in for a back end that unrolls
forloops in context (b) at compile time. It seems to require eitherifstatements nested as deeply as the number of loop iterations, or calling a sub-control and usingreturn, or a newgotostatement.
I propose that the two possible forms that the for loop iteration be:
(1) for (<type_specification> <loop_variable_identifier> in <tuple_expression>) <loop_body>
It is a compile-time error if you attempt modify the value of out or inout parameter in any function/method/sub-control/sub-parser call, in the
(2) for (<assignment_statements>; <boolean condition>; <assignment_statements>) <loop_body>
where
New variables whose scope is local to the for loop can be introduced in the first for (bit<9> i = 5; i < 10; i = i + 1) <loop_body>. We need some kind of check at compile time to ensure that the loop has a finite number of iterations. One approach would be that there is at least one variable initialized in the first out or inout parameter in the
TODO: One possible restriction would be that all loop variables in the parentheses after for are new local variables, local to this for loop, and are out of scope outside of the for loop. That seems to simplify questions of what happens if it is a variable declared in an enclosing scope, e.g. we don't need to specify any final value for the loop variable(s), because they cannot be accessed after the loop has finished execution.
thantry
jnfoster
mihaibudiu
rcgoodfellow
Personnel
Design
Implementation
p4-spec:p4c: Only the beginnings of proposed changes to the language grammar in this PR: https://github.com/p4lang/p4c/pull/4120Process
p4-spec:p4c:=======================================