Standard VHDL Preprocessor

The proposed solution is a standard set of preprocessing directives. It should properly fit with the VHDL standard tool directive that was introduced in VHDL 2008. The point is that it should be consistent with other tool directives such as the IP protection pragmas.

In order to support the requirement that tools provide pre-defined information about the context of an analysis, a set standard pre-defined macros will required.

Provision will be made for macro definition in order to support effective constant expressions that can be used to decide on conditional inclusion of text. The data type of a macro and expression evaluation are completely independent of vhdl syntax and grammar, of necessity. You cannot reference vhdl objects to drive conditional compilation. Conditional compilation is preprocessing action.

Features

• define and undefine of an identifier (i.e., a macro definition)
• simple constant expressions invloving such identifiers
• expression operators and, or, not, and defined
• if,elsif, else control structure
• a standard set of predefined identifiers that at least include language version
• source file inclusion
• directives for controlling line numbers(ala #line) and error handing (ala #error)
• conforms to the syntax of a standard tool directive defined in VHDL 2008 LRM

From the 1076-2008 LRM:

A tool directive directs a tool to analyze, elaborate, execute, or otherwise process a description in a specified manner. A tool directive starts with a grave accent character and extends up to the end of the line.

tool_directive ::= ` identifier { graphic_character }

Source file inclusion

This issue strikes at strongly held beliefs about VHDL, what is pure and good. I can make 3 points about it:

1) It is valuable part of a basis set of preprocessing features that supports good source code organization.

2) The VHDL language will remain devoid of file references. There is no compromise the vhdl library conceptual model and invalidation of compiled design units. Compilation of src code happens and managing a set of files, using source code control, using make file systems, etc. to drive compilation are realities. Include files are a rational part of that reality

3) It is quite possible to consider delivering a preprocessor in a separate 1076.x standard as a packaging mechanism.

As there as been good discussion of this point on the reflector, I captured this thread.

Other Discussion

I welcome any proposed addition the standard set of predefined identifiers.

I would also propose not to support macro arguments at all which severely limits their usefulness for defining shorthand notations in the language. It might make sense to further limit the scope of where macros may be referenced to within tool directives only. This is may be overly harsh and in fear of bad behavior at the src code level. A key goal behind it is preserving the self-documenting nature of vhdl in source code.

After we have general consensus on the scope of this solutuion, it will be worth specifying a complete proposal.

Rationale

A good basis set of features for a preprocessor can be considered by starting from existing preprocessor definitions. Those features can be pared down or enhanced by considering whether they meet or conflict with our needs (or sensibilities). This does not mean that the syntax used in such preprocessors is important to preserve. To me, it is only forming a candidate set of features.

I am aligning this to subset of features in ANSI C preprocessor, which has a rigorous model for conditional compilation that has stood a good test of time. It is easy to refer to its features in a simple way before we harden our specification. I am not maligning another alternative preprocessor definition and it would be fine to make comparisions.

I was initially ambivalent about certain features in the C preprocessor line #line and #error being necessary. I started by excluding them, but they have important value, as others have pointed out. It validates my model for conceptualizing a basis set.

-- JohnShields - 2011-09-21

Comments

Peter Flake has evaluated this idea and posted this:

Of the 6 use cases you list, I feel that only cases 4 and 6 really need a pre-processor. The others could be dealt with by coding style, pragmas or new language features.

I think that your pre-processor proposal is much richer in features than needed to satisfy those two requirements: Boolean expressions and file inclusion for example.

I think you only need:

. `define and `undefine of an identifier (also define from tool invocation) . `if,`elsif, `else, `endif control structure (can be nested) . a standard set of predefined identifiers that at least include language version

This avoids the need for `line. Constant expressions can be created by nested `if and `define. Such a simple pre-processor can easily be built into a lexer.

-- JohnShields - 2011-09-22

The 2 use cases he refers to are these:

• protoyping code to workaround a tool bug or missing language feature, particularly in new analysis or optimization modes of those tools
• migrating code that emulates features of vhdl 2008 in 2002 syntax to using first class 2008 constructs and references

We did discuss the other use cases as being part of the same problem of working around a tool bug, extension or missing language feature where the use case points to a specific conditional compilation action. They get at the granularity of acting on the source code. Regardless, the contribution here is narrowing the basis set of features.

I remain a proponent of include, because of the composition model of instantiation of cond code across a set of files and the action to re-configure the compilation requiring inspection of all files and touch labor on each relevant file. It is unproductive. One has to argue the problems with having include. So far, the only issue is the idea that it would refer to a file. Src code as a collection of files is fairly fundamental data organization and preprocessing does not contaminate or affect the first class language by supporting file references.