Skip to content

LDWG meeting minutes, December 16, 2019

Jump to bottom
Nate Foster edited this page Dec 16, 2019 · 1 revision

Attendees

  • Mihai Budiu (VMware)
  • Calin Cascavl (Barefoot / Intel)
  • Chris Dodd (Barefoot / Intel)
  • Eileen Feng (Google)
  • Nate Foster (Cornell)
  • Stefan Heule (Google)
  • Konstantin Weitz (Google)
  • Jed Liu (Barefoot / Intel)
  • Alan Lo (Mellanox)
  • Vladimir Gurevich (Barefoot)
  • Andy Fingerhut (Cisco)
  • Chris Sommers (Keysight)
  • Marko Stanojlovic (RT-RK)

Status

  • ONF's code of conduct was added to the GitHub repository, with approval from the P4 TST.

  • A new P4-target, Cisco's Silicon One was announced.

Pure Function Annotations

Summary

  • The front-end and mid-end do various transformations and optimizations, and need to have semantic information about the externs provided by the architecture.

References

Status

  • @ChrisDodd created a pull request on the p4c compiler, which is linked above.

  • There was an extended discussion on how to capture the notion of side effect freeness.

Discussion

  • We discussed several possible ways that a given function or method might be safe to transform in the compiler. These could be @pure functions, or @noSideEffects.

  • Of particular interest is the LocalCopyProp transformation. For example, we'd like to be able to optimize code that contains read and write operations on registers.

  • Memoization in the sense of returning the same result when applied to equal gruments was proposed as a criterion, but as stated it doesn't rule out side-effects on other state.

  • Now that we have functions, we could write some functions like min and max, at least at certain types, in the language.

  • Note that we could allow the backend, which understands the semantics, do these transformations. But we agreed it is better for the architecture description to provide more information to the compiler and programmers.

  • We recalled that currently extern functions are essentially arbitrarily powerful (see Section 6.7.1).

Action Item

  • @jafingerhut to assemble a suite of examples and non-examples.

  • @ChrisDodd to then create a pull request on the specification.

Structured Annotations

Summary

  • The API WG observed that the move to free-form, unstructured annotations requires re-implementing various forms of parsing redundantly. The goal of this item is to allow structured annotations using a special syntax.

References

Status

  • The proposal seeks to add structured annotations indicated by [ ... ]

  • Within the brackets one can have a list of expressions or key-value pairs.

Discussion

  • We weren't sure whether it should be allowed to mix and match lists and key-value pairs in the same annotation.

  • We discussed where annotations may appear -- essentially on declarations with a few exceptions like keys in tables.

  • What happens if you mix structured and unstructured in the same annotation? Update: actually the proposal says they cannot be mixed.

  • We considered eliminating lists for simplicity, but also observed this hurts reusability.

  • This proposal could be realized by (i) eliminating lists and (ii) optionally introducing a default "empty" key. We'd then have to concatenate the lists when merging.

  • To further simplify, we could also not merge structured annotations.

  • But not merging would be a breaking change since the compiler currently merges.

  • Some folks noted that single-annotation is useful.

  • Allowing annotation by empty list might be useful.

  • We decided to eliminate merging for all annotations.

  • We also decided to consider adding empty annotations and discussed several alternatives.

Action Item

  • @chrispsommers will update the pull request to reflect this discussion

Implicit Casts Involving Serializable Enums

Summary

  • We made a change in v1.2.0 to allow implicit casts between seriazable enums and their underlying bit type in one direction, which broke an existing compiler test.

Reference

Status

  • The current language does not allow a simple-looking example involving a cube expression to be type checked.

Discussion

  • The example involves a table whose key is a seriazable enum, and it has an entries property with a cube specified in terms of one of the values in that enum.

  • We discussed two alternatives:

    • Allow casts between the enum and the underlying bit type in both directions.

    • Extend cube expressions to serializable enums.

  • We could replace the text in Section 8.12.3 so that the arguments to &&& do not have to have the same type. Instead, we say that the two arguments need to have the same (or perhaps compatible types) and produces a set whose elements have the same type as the left argument.

  • We briefly discussed when the enums are eliminated in the compiler and conjectured that it was late enough that the P4 Info file has the mapping.

Action Item

  • @mbudiu-vmw to see whether the second approach works for the problematic example and to add some additional tests.

Default Values

Summary

  • We have added new constructs for initializing struct-like values, but have not yet finalized a design for default values.

Reference

Status

  • We have several proposals for default values

Discussion

  • There are two proposals: (i) what are the default values for each type and (ii) what's the notation for specifying when to populate a struct-like value with defaults.

  • The defaults are usually the smallest or "zero" for that value.

  • The proposed syntax for defaults is ....

  • Some felt that omitting the ... would be preferable. For example, consider extending a structure and having the compiler point to the places where some code needs to change.

  • We discussed whether this is compatible with optional arguments.

Action Items

  • @mbudiu-vmw will complete the implementation and then this looks good for adding to the language in v1.3.

Next Meeting

  • January 6th, 2020
  • Please read and comment on the proposed (simple) module system.
Clone this wiki locally