Ultimately, the goal is to completely separate the compilation from
the runtime to make it possible to have the interpreter/evaluator
be "just another" entity that can perform meaningful work when
given a parsed GP4 program.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
In P4, parsers are considered types. Those parsers are instantiated.
The instantiated parsers are values. Previously, gp4 treated a parser
type and a parser value as identical. This PR makes that difference
clear _and_ sets the stage for the future.
TODO: Make the same distinction between control and action types and
values.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
When the user gives relative path names for p4 files, report
those in error messages (etc.). The SourceManager can/does
resolve those to absolute path names.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Implement a generic visitor for components of a P4 program and use
it to start P4 code generation (according to the behavioral model).
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Make it possible to output formatted error messages using a
flexible API that includes an ability to specify styles and
formatters.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
For types, make it optional to return a default value. While default
values for some types are meaningful, they are not meaningful for all
types (e.g., Action, Control, Parser, Parser state, etc.).
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
The compilation code was written as a precursor for implementation
with macros. The updates in this commit make the switch.
There is still plenty to do:
1. Comment Walker.
2. Comment Macros.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Move as much of the common functionality of executing a block
of statements into a common area as possible.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Allow the user to customize the evaluation/execution of expressions/
statements with something that implements functions that perform
those tasks. This additional functionality will make it possible for
the "classic" evaluator not to waste time checking for the presence
of interlopers and give implementers additional customization opportunities.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Centralize the execution of statements and evaluation of expressions
so that the user can specify a debugging "callback" after every
execution/evaluation.
The callback can be used for myriad things, but it seems likely that
it will be useful for implementing:
1. Testing
2. Debugger
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
When a function is called, if there is an (in)out parameter,
make sure that updated values are propogated to the calling
function.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
The type system (and the value system) now include attributes
for each type (things like direction, const-ness).
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Add support for directions on parameters and attributed types. The
latter is necessary to support the former, but is not limited to
the direction use case. An attributed type is a P4 type with attributes
(like its direction, whether it is read only, etc.) Other attributes
will be added in the future.
Changes necessary to support attributed types include:
1. Global instances tracked during compilation are not attributed
types and not simply types.
2. (future) Type checking will have to make sure that a types
attributes do not affect type compatibility.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Fields were not given default values when a struct was declared
without initializers.
Also, cleanup code in the helper function for binary operations
on struct instances.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
1. Add support for field access
2. Add support for proper type checking of array access
3. Add tests for nested field and array access
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Will Hawkins