Posted by Mihai Budiu and Nate Foster on October 30, 2019
On behalf of the entire P4 Language Design Working Group, we are pleased to announce version 1.2.0 of the P416Language Specification.
The official specification document is available in HTML and PDF on the P4 website.
Overview
Most of the features added in version 1.2.0 can be characterized as “ergonomic improvements” rather than dramatic changes to the language. The modest scope of these changes reflects our commitment to stability, which was made when P416 version 1.0.0 was first announced at the P4 Workshop in May 2017, and indicate that the foundations of the language are sound.
In particular, due to P416’s target-architecture separation, it has been possible to add new features to specific architectures without having to change the language. For example, the V1Model architecture nows support assertand assume functions as externs, which can be used to document and check properties that hold during the execution of a P4 program. Adding these features did not require making any modifications to the language specification.
However, as members of the P4 community have gained experience using the language to build new systems, the need for a few new features become apparent and some pain points emerged. P416 version 1.2.0 attempts to address these needs. Following is a brief summary of the main technical changes made in this version of the language.
String and Int Types
The language now exposes string and int types to programmers. Previously these types were used internally by the compiler to give types to string and integer literals but could not be used directly by programmers.
Now, the string type can be used to specify the type of extern functions such as,
extern void log(string message);
which might be useful for adding debugging information to a log on a software switch.
Similarly, the int type is useful for specifying the type constructor parameters that control the size of elements such as tables:
control c(...)(int n) {
table t {
...
size = n;
}
}
To ensure that strings do not require excessive run-time computation, int and string can only be used with compile-time known values—i.e., literals and operations involving literals.
Bit Types
One of the design goals behind P416 was to give a clear semantics to all expressions that manipulate bit values. To this end, version 1.2.0 clarifies that the language supports 1-bit signed values. It also clarifies that the result of a bit slice is unsigned, even if the value being sliced was signed. For example, after evaluating the following declarations,
int<9> x = -1;
bit<1> b = x[9:9];
the value of b will be 1.
Casts on Enum Values
P416 version 1.1.0 added serializable enums, which allow the programmer to specify an underlying type for enumerations. In version 1.2.0, enum values with a specified underlying type, such as
enum bit<2> E {
A = 0;
B = 1;
C = 2;
D = 3;
}
are now automatically cast to the underlying type. For instance, the following statements are legal:
E e = A;
bit<2> b = e;
We expect that this feature will be useful when writing parsers that handle headers whose fields are specified using enum types. Previously a cast was required when selecting on such fields, which was tedious for programmers. Now the types can be converted automatically by the compiler.
Header Type Sizes
As a convenience, the language now offers two operations to calculate the minimum size of a header type, h.minSizeInBits() and h.minSizeInBytes(). These operations are similar to sizeof in C and C++. Note however that while the minimum size of a header can be determined at compile time, the run-time size may be larger—e.g., if it contains fields whose type is varbit.
Annotations
Annotations provide a mechanism for extending P416 without having to modify the grammar and the rest of the front-end. To accommodate a variety of possible annotations, some of which are target-specific, we have relaxed the syntax of annotations so that they may contain any sequence of terminals, so long as any parentheses are balanced.
At the same time, some standardized annotations may mandate specific structure—e.g., the @name annotation has a string as its body while the pkginfo annotation used by P4Runtime takes a list of key-value pairs. We imagine that in the future, the structure of other annotations may become de facto or official standards.
Acknowledgments
As always, developing this new version of the language specification was a community effort. It represents months of hard work by the entire P4 Language Design Working Group. Please see the minutes from our monthly meetings, which are posted on the LDWG Wiki for details about the key contributors to each feature.
Get Involved!
We plan to release version 1.3.0 of the specification in late spring 2020. The Language Design Working Group is already discussing several features to focus on for this release including enhancements to the type system, architecture,s and run-time APIs, among other features.
If you’d like to get involved, please sign up for the P4 Design mailing list, or join our monthly meetings. We typically meet on the first Monday of each month at 11am PT. You can find details at the P4 Working Group Calendar.
