'int' type

[ChrisDodd]

Section 7.1.6.5 talks about the type int

7.1.6.5. Infinite-precision integers

The infinite-precision data type describes integers with an unlimited precision. This type is written as int.

This type is reserved for integer literals and expressions that involve only literals. No P4 runtime value > can have an int type; at compile time the compiler will convert all int values that have a runtime > component to fixed-width types, according to the rules described below.

However, the grammar in the appendix does not recognize int as a type (only int< integer >). P4_14 (v1.1) used int in declarations of extern functions where the argument needed to be a constant and had no particular bitsize. Should something similar be allowed in P4_16? What exactly does it mean -- an argument that must be a compile time constant (generally a literal or expression involving only literals?)

[jnfoster]

@mbudiu-vmw should weigh in, but I believe this is intentional. int is not a type the programmer can write down, just an internal type used by the compiler. If that understanding is correct, the text should be tweaked to clarify.

We define compile-time known values precisely at the start of Section 16. Would it help to add a link or would that just add clutter?

[ChrisDodd]

In that case, we should probably remove "This type is written as int", as that suggests int can be used to denote the type. Its not clear what, if any, connection there is to section 16 compile-time known values.

[ChrisDodd]

The place this comes up is things the 'index' arguments to counter/meter methods. In v1model.p4, these are generally defined as bit<32>, which generally means that the user needs to explicitly cast the argument they use to bit<32> if it is of some other type (which it often is if it comes from an action parameter). It would be nice if there was a way to define an extern that "just worked" without the need for extra casts and type specifiers.

[tomrodeheffer]

And then there are constant declarations.

A constant declaration does not construct a P4 runtime value, but rather a P4 compile time value. So there is no reason why you should not be able to write a constant declaration of type int, for example:

const int threshold = 150 + (6 / 2);

which would then permit the programmer to use threshold everywhere in the P4 program where formerly there occurred the magic constant 153.

Except that the grammar does not permit it, since you cannot actually write int for a baseType.

[jnfoster]

That's a good observation. Indeed, it'd be fine to allow `int`s as constant declarations. On the other hand, if one wanted to play devil's advocate, one could argue against allowing this for the sake of uniformity -- in general we've tried to keep the set of types as orthogonal and composable as possible. Having a type that could only appear with a `const` preceding would go against that principle, and would add one more exceptional case that P4 programmers have to remember. Note also that the language would become Turing complete if we allowed `int`s as a non-const type with the full set of numeric operations on them. So adding `int` to the set of allowed `baseType`s quickly gets us into deeper waters. Overall, I don't feel strongly about this issue. I suspect that most people are working around this issue by using `cpp` macros instead of `const` declarations, which is obviously not great. So I could definitely be in favor of relaxing this in a future version of the language. In the short term, I'd propose tweaking the wording in the spec to avoid confusion. If folks agree, does @cdodd want to make a PR or should I?

…

-N

On Tue, Jun 27, 2017 at 11:52 AM, Tom Rodeheffer ***@***.***> wrote: And then there are constant declarations. A constant declaration does not construct a P4 runtime value, but rather a P4 compile time value. So there is no reason why you should not be able to write a constant declaration of type int, for example: const int threshold = 150 + (6 / 2); which would then permit the programmer to use threshold everywhere in the P4 program where formerly there occurred the magic constant 153. Except that the grammar does not permit it, since you cannot actually write int for a baseType. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#331 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABwi0nAqSC3MksYRv9XlKhE1zqbCrtRcks5sIU-IgaJpZM4OGMWz> .

[mihaibudiu]

Internally the compiler uses InfInt for this type. The problem is that bit is an abbreviation of bit<1>, but int is not an abbreviation of int<1>.

We can add int to the grammar; it would make sense indeed for writing some constant values, as @tomrodeheffer proposes, and also for constructor argument types. But it is not clear that the value provided is worthwhile.

[jnfoster]

@mbudiu-vmw proposes that we change the name of this type due to the confusing asymmetry with int types.