Re: [vhdl-200x] conditional compilation response

On 24/08/2011, at 4:17 PM, Shields, John wrote:

> I will say that preprocessing itself is an implementation decision. It can be done in the context of the lexical analysis phase of the analyzer and often is. The real requirement is that it is not encumbered with first class language features and is compatible but orthogonal to the language syntax. Standardizing it for vhdl has real value for portable code composition. I only expressed it in my proposal as a preprocessor with a subset of C preprocessing features to make the high level ideas clear.

Orthogonal implies the name space for preprocessor directives is independent from VHDL object name space. Compatible implies which ever one comes first (preprocessor or lexical analysis) has no trouble distinguishing syntax. It's how you get conditional text to behave identically either internally or externally implemented.

Someone could look at the the gnatprep preprocessor
http://www.adacore.com/wp-content/files/auto_update/gnat-unw-docs/html/gnat_ugn_18.html

and infer John's starting point:
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
conforms to the syntax of a standard tool directive defined in VHDL 2008 LRM
Considering some of the requirements and non-requirements mentioned by Jim Lewis and how the languages are related it's not too surprising the two can be similar.

There's a bit of an issue with design hierarchy which currently goes design file -> design unit, and conditional text sort of implies design file -> design description -> design unit. There can be implementation methods that would require intermediary files were token backtracking required and external preprocessing used. Conditional text uncouples the design unit from the design file.

Standard compliance could infer implementation decision above and beyond ease of implementation, forcing an internal implementation versus a preprocessor. It'd be nice to not put anyone on the hook. (And no, my own lexer doesn't use backtracking).

Anyway, I stopped and learned how to do preprocessing to the boundary between the lexer and parser in my analyzer after John's cryptic remarks. It's not as bad as I thought although I'm toying with the idea of a separate symbol table for it. There's precedent I already have a separate store for the implementation dependent mapping of design library simple names to library paths because I also have a tiny parser using the lexer for reading an init file. It gives me the ability to redirect the file input while preserving and restoring seek location and can use a separate input buffer. That would support source file inclusion.

I was originally convinced implementation would be a pain, but that's not really the case. I also use a derivative of the lexer in a DMSL tool and can see how easy it would be to write an external preprocessor as well.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.