forked from jafingerhut/p4-guide
-
Notifications
You must be signed in to change notification settings - Fork 0
/
p4-16-allowed-constructs.txt
157 lines (138 loc) · 6.08 KB
/
p4-16-allowed-constructs.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
The contents of this document have been compared against Appendix F
"Restrictions on compile time and run time calls" of the P4_16
v1.1.0-rc as of this git commit on 2018-Aug-11, and they appear to
match each other:
$ git clone https://github.com/p4lang/p4-spec
$ git checkout 015f9225ea022a337d986a9d2905f81bc6741217
TBD to add:
* extern function declaration
* extern function call
[*] Mark on things that are only allowed in, or most useful within,
architecture model files.
top level
[*] type declarations for parser, control, package
[*] extern function and object declarations
const
typedef
header
header stack
header_union
struct
enum
error
match_kind
instantiation of extern object, parser value set
instantiation of package (there must be one named 'main')
function definition
const, variable decl, assignment, function call, return <expression>
if
anything allowed directly inside function
NO: action call
action - see 'action' below
NO: instantiation of control block, parser
NO: variable decl
NO: state, table
parser
const, variable decl
instantiation of extern object, parser, parser value set
NO: instantiation of control block
state
const, variable decl, assignment, function call
NO: action call
extern object method call (p4test allows, p4c-bm2-ss allows some, e.g. packet.extract(), but not others, e.g. count1.count() TBD: how does it decide which?)
<subparser>.apply()
block statement { }
anything allowed directly inside state
transition <statename> (must be last in state definition)
transition select .... (must be last in state definition)
call to a parser value set, as a key set expression
NO: type definitions
NO: if, switch, return, exit
NO: parser, state, action, table, control
control
const, variable decl
instantiation of extern object, control block
NO: instantiation of parser, parser value set
action
const, variable decl, assignment, function call, action call
extern object method call
return, exit
if - Note that P4_16 language spec warns that implementations need not support 'if' inside of actions.
anything allowed directly inside action
block statement { }
anything allowed directly inside action
NO: type definitions
NO: switch, transition
NO: parser, state, action, table, control
table
key = { ... }
actions = { <action_spec>; ... }
default_action = <action_spec>;
apply { } (body of control block)
const, variable decl, assignment, function call, action call
extern object method call
<table>.apply()
<control_name>.apply()
switch (<table>.apply().action_run) { ... }
anything allowed directly inside control body apply { }
return, exit
if
anything allowed directly inside control body apply { }
block statement { }
anything allowed directly inside control body apply { }
NO: type definitions
NO: transition
NO: parser, state, action, table, control
The table below lists all types that may appear as members of headers,
header unions, structs, and tuples. Note that int means an
infinite-precision integer, without a width specified.
The two-argument extract method on packets only supports a single
varbit field in a header.
This table has been reviewed and approved by the P4 language design
work group, but the latest p4c compiler as of 2017-Apr-11 does not
accept some of the types marked as 'allowed' inside of structs. The
bmv2 behavioral model also does not yet support nested structs.
+--------------+--------------------------------+
| | Container type |
| | |
| | | header_ | struct |
| Element type | header | union | or tuple |
+--------------+-----------+---------+----------+
| bit<W> | allowed | error | allowed |
| int<W> | allowed | error | allowed |
| varbit<W> | allowed | error | allowed |
| int | error | error | error |
| void | error | error | error |
| error | error | error | allowed |
| match_kind | error | error | error |
| bool | error | error | allowed |
| enum | error | error | allowed |
| header | error | allowed | allowed |
| header stack | error | error | allowed |
| header_union | error | error | allowed |
| struct | error | error | allowed |
| tuple | error | error | allowed |
+--------------+-----------+---------+----------+
----------------------------------------------------------------------
Type declarations for parser, control, package
----------------------------------------------------------------------
Type declarations for parsers, controls, and packages do not define
the behavior of those things, nor do they instantiate such a thing.
They only declare the thing's signature.
All of them have the general syntax like this, with the only
difference being the keyword 'parser', 'control', or 'package':
[ <annotation> ] control <name> [ <type parameters> ] ( <parameters> );
Relevant symbols in grammar:
parserTypeDeclaration
controlTypeDeclaration
packageTypeDeclaration
Examples, from file "very_simple_model.p4" in P4_16 spec:
parser Parser<H>(packet_in b,
out H parsedHeaders);
control Pipe<H>(inout H headers,
in error parseError, // parser error
in InControl inCtrl, // input port
out OutControl outCtrl); // output port
package VSS<H>(Parser<H> p,
Pipe<H> map,
Deparser<H> d);