RE: [vhdl-200x-dta] Review of: [vhdl-200x] Revised white paper on type genericity

Jim,

> In section 2 and 3, can we make the is keyword on packages
> and subprograms (and entities) optional. Then we would have
> better syntax consistency:
>
> package_declaration ::=
> package identifier [is]
> [ formal_generic_clause ]
> package_declarative_part
> end [ package ] [ package_simple_name ] ;

That's a separate issue, so no comment.

> In section 2.1, instancing packages
> Let me restate a couple of things to make sure I understand:
> When instantiated as a design unit, an instanced
> package can be referenced like any other package.

Correct.

> Of the two below, which is right?
> 1.1 seems intuitive, 1.2 seems problematic.
> ??1.1 When instanced in a declarative part (entity,
> architecture/block, process, ...) the instanced
> package can only be made available in the immediate
> declarative part (or declarative parts within
> its scope - ie: if declared in an architecture the
> package is selectable a block within the architecture)
>
> ??1.2 When instanced in a declarative part (entity,
> architecture/block, process, ...) the instanced
> package is still a primary unit and is compiled into
> the same library as the design that contains it and
> can be referenced by other designs.

1.1 is close, 1.2 is incorrect. When a package is instantiated in a
declarative region, the package instance is treated as a named entity in
that region. The usual scope and visibility rules apply, so the package
instance would only be potentially visible in the region in which it is
declared.

The generic package is elaborated as part of elaboration of the declarative
region. Hence, there is an instance of each of the internal declarations of
the package, and those instances are contained within the package instance.

We would revise the semantics of expanded names to allow a prefix to denote
a package instance; in that case, the expanded name would refer to a named
entity within the package instance. In other words, a named entity in a
package instance would be visible by selection in the suffix of an expanded
name for which the prefix denoted the package instance.

We would also revise the semantics of use clauses to allow a use clause to
refer to a package instance, in which case it would make named entities from
the package instance visible in the scope of the use clause.

> -- Potential enhancement request if it is not already this
> way -- When a package is instanced in the declarative part,
> the package use clause seems repeative. This is best
> illustrated in the example at the end (page 6/7):
> package test_pattern_tables is new work.lookup_tables
> generic map (
> element_type => test_pattern_type,
> key_type => string,
> key_of => test_id_of
> );
>
> -- the following use clause seems redundant.
> use test_pattern_tables.all;
>
> Would it make sense that if a package is declared in a
> declarative part, then a use clause to reference it is
> automatically implied.

No. What if you have multiple instance of the same package but with
different actual generics?

> -- Potential enhancement request if it is not already this
> way -- Furthermore, if the context design unit proposed in fast track
> (FT16) is accepted, perhaps we could do a similar implied
> reference for the package:
>
> Context Chipper_Context is
> library std ; -- not needed?
> use std.standard.all ; -- not needed?
> library work ; -- not needed?
> library ieee ;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all ;
> use std.textio.all ;
>
> package floatpkg is new ieee.genericfloatpkg
> generic map (
> numeric_type => real
> );
>
> -- use work.floatpkg.all ; -- implied
>
> end;

Same problem.

> In section 2.1, if I instantiate a package in a process,
> can a procedure in the package access signals by side-effect
> just like a procedure declared in a process can? My thought
> is probably not, ...

Your thought is correct. The signal is not in scope in the package
declaration. It's like asking whether a design entity that you instantiate
in an architecture can directly access signals from that architecture. No,
it can't, since they're not in scope in the instantiated design entity. The
design entity can only indirectly assess them if they're associated with
ports of the design entity.

> ... however, what if we took the next step and
> port mapped signals and variables to a package and
> instantiate the package in the process. Now I think I will
> effectively get side-effect access in a procedure.

Why not just declare signal and variable parameters on the procedure?
That's what they're for. The idea is to make the interfaces and data
connections explicit, rather than having a spaghetti tangle of side-effects
and implicit cross references.

> In section 3, Subprograms, I prefer the v1 subprogram generic format
> where:
> subprogram specification ::=
> procedure designator
> [ generic ( generic_list ) ]
> [ [ parameter ] ( formal_parameter_list ) ]
>
> | [ pure | impure ] function designator
> [ generic ( generic_list ) ]
> [ [ parameter ] [ ( formal_parameter_list ) ] return type_mark
>
>
> If we do this, I would prefer we use the key word port to parameter.

To some extent, this is a matter of taste. My v1 proposal makes subprograms
consistent with the style of other units that have interfaces, but it's a
signficant departure from the normal programming-language style that people
are used to. The v2 proposal is more in line with the latter, and is
cribbed directly from Ada.

Regarding the keyword in the v1 proposal: I would definitely not use port,
since a port list is for interface signals only, and has associated static
semantics (eg, relating to default expressions). A subprogram has a
parameter list, with semantics that are different from port lists. Using
the keyword port for parameters would be a really bad idea.

> In section 3.1, the following seems to be missing:
>
> entity_declarative_item ::=
> . . .
> | generic_subprogram_instantiation

Oops - I got confused. While subprograms in an entity declarative part
aren't visible outside the entity declaration, they can be included for the
benefit of associated architecture bodies. Generic subprogram instances
should also be allowed in the same way. I will amend the document.

> In section 4 and 5, why were package generics deleted?
>
> interface_declaration ::=
> . . .
> | interface_type_declaration
> | interface_subprogram_declaration
> | interface_package_declaration
>
>
> actual_designator ::=
> . . .
> | type_mark
> | subprogram_name
> | package_instance_name

One reason was to keep the extensions simple. Recall that in v2 I
simplified the formal types by removing the specification of the "shape" of
the type. This makes generic packages less useful for other than container
data structures. So you're not likely to see them used for abstract data
types that define lots of computational operations. The example of formal
packages in v1 was for generic packages that defined new types based on
floating-point types and new arithmetic operators over those new types.
Formal packages avoided the need to pass lots of subprograms for the
operators on the floating-point types used.

If all we're going to do is define container types using generic packages,
the need for formal packages is much less. One scenario that comes to mind
is if we wanted to define a generic container package that provided
operations on container types. The specific container types would each be
defined in generic packages that all provided the same operations. A type
from an instance of one of these packages, along with the package instance
itself, woud be passed as the actual generics to the generic container
package. That package would use the operations from the actual package to
implement general container operations. A model could then use the general
container operations independently of what particular data structure was
used. The underlying data structure could be change by changing the package
instantiations.

But if you think about this scenario, it would be better expressed with OO
facilities and subtype polymorphism. That was something we want to address
in a subsequent revision of the language. The brief for the current
revision is to provide generics in a form that won't prejudice future
extensions. Hence, I removed formal package generics.

> Section 6:
> An interface type declaration defines a formal generic type
> that can denote any type. The generic unit can only assume
> that operations available for all types are applicable,
> namely, variable assignment, equality and inequality operations.
>
> I like the simplified format, but why limit the operators we
> can use? It does seem to give us the ability to solve some
> short term issues in the verification realm. This is not a
> bad compromise answer/first step for fast track.
>
> When going further, perhaps a good test case for usage of
> other operators are the issues David Bishop is having with
> floating point implementation and swapping the use of real
> (simulates fast) vs. array (accurate in size).

The rationale is to ensure that static type checking can still be done in
the context of separate analysis. When analyzing a generic unit, you have
no static information about the actual types that could be provided in
different instantiations. But you want to guarantee that no type errors
creep through to elaboration or run time.

Given these requirements, I have revised the document to be more specific
about rules governing formal and actual generic types. The revised wording
in section 6 is:

  An interface type declaration defines a formal generic type that can
  denote any constrained type, except a file or protected type or a type
  with a subelement that is a file or protected type. The generic unit
  can only assume that operations available for all such types are
  applicable, namely, variable assignment, equality and inequality
  operations. The formal type cannot be used as the type of a constant,
  signal, file element or attribute.

  When a generic unit is instantiated, an actual type must be a constrained
  type and cannot be a file or protected type or a type with a subelement
  that is a file or protected type.

I think the kind of things David is trying to do with alternate
implementations of the floating point package are beyond what we can achieve
with type generics, even with the v1 proposal. He's really looking for
build-time configuration of which package body to use.

> Section 7:
> In the example, in the procedure body of traverse, where does
> the procedure action come from? It looks like it was a
> generic on the interface to traverse and that perhaps it was
> accidentally removed as the example on the bottom of page 6,
> top of page 7 seems to map the subprogram.
>
> procedure traverse ( table : in lookup_table ) is
> begin
> if table = null then
> return;
> end if;
> traverse ( table.left_subtree );
> action ( table.element );
> traverse ( table.right_subtree );
> end procedure traverse;

Yes, the action procedure is a generic to the traverse subprogram. It is
specified in the generic list in the subprogram declaration in the package
declaration. In the package body, the generic list is optional in the
subprogram body. The wording from Section 3:

  If a generic subprogram is declared as a separate subprogram declaration
  and subprogram body, the subprogram body may include the formal generic
  clause, in which case it must conform with the formal generic clause in
  the subprogram declaration.

This was in response to a comment on v1, and is closer to what Ada does
also.

Hope this answers you questions sufficiently. Please let me know if further
clarification or elaboration is needed.

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106