[P4] Fwd: [P4-design] P4_16 v1.0.0 Release Candidate

[Sándor Laki]

-------- Forwarded Message --------
Subject: 	[P4-design] P4_16 v1.0.0 Release Candidate
Date: 	Mon, 15 May 2017 21:47:05 +0000
From: 	Gordon Brebner <Gordon.Brebner at xilinx.com>
To: 	p4-design at lists.p4.org <p4-design at lists.p4.org>



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.



---
Ezt az e-mailt az Avast víruskereső szoftver átvizsgálta.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/p4/attachments/20170516/acfffeb2/attachment.html>
-------------- next part --------------
_______________________________________________
P4-design mailing list
P4-design at lists.p4.org
http://lists.p4.org/mailman/listinfo/p4-design_lists.p4.org