language-evolution proposal [for discussion]: a standardized, non-pragma indication of [the] supported target[s]

[Abe149]

• a standardized, non-pragma way to tell all P4 implementations what hardware the P4 program in question can possibly work on

• e.g. “supported_targets { "Tofino 2", "Tofino 3" };” meaning that the program in question can successfully be compiled for either Tof2 or Tof3, but probably not for anything else

• to help compilers for other targets — and even otherwise-compatible compilers currently in a different target “mode” — to abort early with a useful error message, rather than “trying hard” and producing a mountain of misleading error messages

[vgurevich]

I think that a clear indication of architecture for which the program has been written (instead of relying on a specific #include file) might be even more useful. Adding the ability to specify the minimum required version of the language spec/frontend/architecture version will also be very useful.

We currently implement some of this using CPP (target and compiler version), we can add architecture version, but language/frontend version is outside of our control.

[mihaibudiu]

This is one reason I proposed a static_assert function

[jnfoster]

Agree with @vgurevich that specifying the architecture in the program is much more in line with the spirit of the P4_16 language than specifying the target.

[Abe149]

@jnfoster Doesn`t specifying an arch. implicitly specify a target?… e.g. “t2na” ⇒ “tofino2”.

[jnfoster]

No. An architecture will often be implemented by many targets. See section 4 of the spec.

[apinski-cavium]

Having a macro for the language version would be useful. My suggestion would be date for the version like C++ does. I don't see how defining a macro for a target would be useful and even more how to standardize it since it would need to be an integer constant as P4 does not have compare strings or even inside of tuples of strings. And that would require full standardization inside the spec itself and releasing specs more quickly with updated targets unless it is a tuple of integer constants where one is the vendor like how ARM does it for their processors:

CPU implementer : 0x43 // 'C' for Cavium
CPU variant     : 0x2
CPU part        : 0x0b2

So only implementer (vendor) needs to be agreed upon.

[jnfoster]

Having a macro for the language version could also be useful, but it seems like a different issue... This one is about specifying the target/architecture.

[mihaibudiu]

We can add string comparisons too

[apinski-cavium]

We can add string comparisons too

And then you need to handle things like '\x34' etc. in strings which right now the spec have the following:

Since P4 does not provide any operations on strings,
string literals are generally passed unchanged through the P4 compiler to
other third-party tools or compiler-backends, including the
terminating quotes. These tools can define their own handling of
escape sequences (e.g., how to specify Unicode characters, or handle
unprintable ASCII characters).

Going string comparison route seems much more troubles than just assigning numbers out for a vendor.

[Abe149]

@apinski-cavium I｀d rather not make this [a] macro[s] if we don｀t have to.

AFAIK, the only valid use-case for macros is e.g.

#if TOFINO2

<... some code...>

#elseif TOFINO3

<... some other code...>

#else

<... some other code...>

#endif

… which IMO is to be avoided at all costs if/whenever possible.

Can you think of any other [e.g. better] use case for having this as macros rather than in the compiler proper?

[jnfoster]

In the interest of tidying up the set of active issues on the P4 specification repository, I'm marking this as "stalled" and closing it. Of course, we can always re-open it in the future if there is interest in resurrecting it.