[P4-design] P4_16 v1.0.0 Release Candidate

Gordon Brebner Gordon.Brebner at xilinx.com
Mon May 15 17:47:05 EDT 2017


Dear P4 Designers,

We have a release candidate for P4_16 v1.0.0:  https://p4lang.github.io/p4-spec/

At this point we are freezing the specification.  However, because many improvements were made over the weekend, we will let it sit for one more day before releasing the official final version.  This will allow any members of this group who have not been following the changes to catch up, and also leaves a small window for fixing any last typos that may have been introduced.  One beautification activity during this extra day is that Calin and Nate are working on fixing the formatting to make it look like the P4_14 spec (https://github.com/p4lang/p4-spec/pull/219) since the fonts in the generated PDF are under-attractive.  We will post the final version at midday tomorrow, in advance of the P4 Workshop on Wednesday.

I give my personal thanks to Mihai Budiu, Andy Fingerhut, Nate Foster, and Andy Keep, who basically worked round-the-clock over the past few days helping to polish this document.

Almost all of the changes made since last week were either editorial in nature or straightforward (e.g., typo fixes).  However there were two non-trivial technical changes that we thought worth communicating to the group (per our technical bug fixes process):


1. We eliminated two-argument emit:

void emit<T>(bool b, T data);

since it can be emulated with the single-argument emit plus a conditional:

void emit<T>(b,data) ==>
if(b) emit<T>(data);

As far as we know, this variant was not in active use.  We also clarified that emit handles headers, header stacks, header unions, and structs recursively built from those types.


2. We simplified the semantics of the setInvalid() method and assignments involving header unions.  Previously the specification said that invoking setInvalid() on a field that is already invalid is a no-op.  Now it invalidates all fields in the union.  Likewise, previously the specification said that assigning an invalid header to an already-invalid union member was a no-op.  Now it invalidates all fields in the union.

We took this change because it is simpler and the old behaviors can be easily recovered if desired:

u.h1.setInvalid() ==>
if (u.h1.isValid()) u.h1.setInvalid();

and

u.h1 = e_h1 ==>
if (e_h1.isValid()) {
  u.h1 = e_h1;
} else if (u.h1.isValid()) {
  u.h1.setInvalid();
} else {
  // no-op
}

Again, as far as we know, there is no code in active use that depends on the old semantics.


Best wishes,
Gordon.



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-design_lists.p4.org/attachments/20170515/83377bcb/attachment-0002.html>


More information about the P4-design mailing list