Physical unit ambiguities

[valtih1978]

Another ambiguity comes from

literal ::= numeric_literal | enumeration_literal | ...
numeric_literal ::= physical_literal | ...
physical_literal ::= [ abstract_literal ] name
name ::= identifier | operator_symbol | character_literal |
selected_name | indexed_name | slice_name | attribute_name
enumeration_literal ::= identifier | ...

For instance, you have a 'second' in the expression. Is it an
enumeration or physical literal? The numerical quantity is optional in
phys. literals, as we see. It seems that this is an incarnation of what
I heard of "context-sensitivity" of VHDL? Does it mean that the parse
tree is ambiguous until after the elaboration?

Moreover, 'name' admits such fancy names as function invocation,
attribute requests and such, which seems to be a nonsense for physical
literal, e.g. 1 miles(3) should be valid according to the LRM grammar.
Language designers could easily ban this "feature" by saying that
physical units are specified by identifiers (aka simple names) rather
than arbitrary names. Why does spec choose the general name production
instead?

 

[KJ]

On Saturday, December 26, 2015 at 8:07:55 PM UTC-5, valtih1978 wrote:

Another ambiguity comes from

literal ::= numeric_literal | enumeration_literal | ...
numeric_literal ::= physical_literal | ...
physical_literal ::= [ abstract_literal ] name
name ::= identifier | operator_symbol | character_literal |
selected_name | indexed_name | slice_name | attribute_name
enumeration_literal ::= identifier | ...

According to VHDL-2000, 2002 and 2008
physical_literal ::= [ abstract_literal ] unit_name

physical_literal is not defined as you have posted as
physical_literal ::= [ abstract_literal ] name

'unit_name' is not further defined in the specifications, however 'unit name' is defined. Darn those inconsistent humans anyway.

Kevin Jennings

 

On Monday, December 28, 2015 at 3:22:46 PM UTC+13, KJ wrote:

On Saturday, December 26, 2015 at 8:07:55 PM UTC-5, valtih1978 wrote:
Another ambiguity comes from

literal ::= numeric_literal | enumeration_literal | ...
numeric_literal ::= physical_literal | ...
physical_literal ::= [ abstract_literal ] name
name ::= identifier | operator_symbol | character_literal |
selected_name | indexed_name | slice_name | attribute_name
enumeration_literal ::= identifier | ...


According to VHDL-2000, 2002 and 2008
physical_literal ::= [ abstract_literal ] unit_name

physical_literal is not defined as you have posted as
physical_literal ::= [ abstract_literal ] name

'unit_name' is not further defined in the specifications, however 'unit name' is defined. Darn those inconsistent humans anyway.

The unit_ part of unit_name is shown in italics, which has meaning:

IEEE Std 1076-2008 1.3.2 Syntactic description:

g) If the name of any syntactic category starts with an italicized part, it is equivalent to the category name without the italicized part. The italicized part is intended to convey some semantic information. For example, type_name and subtype_name are both syntactically equivalent to name alone.

--

You can while away some time reading up on syntactic predicates.

You could also read 5.2.4 Physical types paragraph 5 for the semantic meaning here:

Each unit declaration (either the primary unit declaration or a secondary unit declaration) defines a unit name. Unit names declared in secondary unit declarations shall be directly or indirectly defined in terms of integral multiples of the primary unit of the type declaration in which they appear. The position numbers of unit names need not lie within the range specified by the range constraint.

--

Para 7:

The abstract literal portion (if present) of a physical literal appearing in a secondary unit declaration shall be an integer literal.

--

And para 9:

There is a position number corresponding to each value of a physical type. The position number of the value corresponding to a unit name is the number of primary units represented by that unit name. The position number of the value corresponding to a physical literal with an abstract literal part is the largest integer that is not greater than the product of the value of the abstract literal and the position number of the accompanying unit name.
--

Essentially that unit name has to be a declared primary or secondary unit name, despite trying to abstract it to simply a name. You could note that a unit name is guaranteed to be represented by not just any name, a simple name, 1.3.2:

h) The term simple_name is used for any occurrence of an identifier that already denotes some declared entity.
--

Also see 8.2 Simple names, the first sentence of the first paragraph:

A simple name for a named entity is either the identifier associated with the entity by its declaration or another identifier associated with the entity by an alias declaration.
--

And the following BNF:

simple_name ::= identifier

--

So there's a semantic restriction that limits unit_name to the simple name (an identifier) of a declared unit.

 

[valtih1978]

Ok, in such a complex way you seem to simply say that there is no chance
that any other than simple name succeeds for the unit literal. This
makes sense. Thanks. It seems that parser can reduce the
physical_literal to

physical_literal ::= [num] simple_name

No, wait. I guess they have "abstracted" it to the more general name to
enable extended names! In 2008 you can refer units in the other modules.