Re: [vhdl-200x] conditional compilation proposal

John/Jim - I don't seem to have write access on the wiki. Would you mind
adding these comments? Thanks -

Evan

-----------------------------------------------

I like the proposal, but I have various (quick) comments:

1 - you need to be careful about any rigorous alignment with a subset of
the C preprocessor. It's badly defined, and it's easy to construct
corner cases that behave differently on different preprocessors

2 - One problem with C-style conditional inclusion (not "compilation" -
#if, #ifdef, #ifndef, #elif, #else, #endif) is that you need an
expression parser to handle the condition. Should the expression use
full VHDL syntax, or a simplified subset? C (and your proposal) uses a
subset, which potentially causes problems - an expression in the
preprocessor does not necessarily evaluate in the same way as the same
expression in the normal code

3 - Do you see this as running in a preprocessor stage, or as part of
the VHDL compiler? You appear to be saying the former. This is pretty
fundamental:

(i) Preprocessor would be more conventional, and is easier to retrofit

(ii) But - implementing it as a preprocessor brings up the problem in
(2) above

(iii) Implementing it as part of "the language" would probably be
difficult. Just "turning off" compilation in an existing compiler is
going to non-trivial in a multi-stage compiler, and may be impossible
without significant rework (note that excluded generates don't currently
turn off compilation)

4 - Having a new preprocessor would be an excellent opportunity to get
Unicode support on the cheap. The preprocessor could convert non-ASCII
Unicode into extended ASCII identifiers, and everything else might (I
think) just work. This does require fixing elsewhere, because extended
identifiers are badly defined (in terms of 'graphic characters'), and
can't currently be used to code arbitrary Unicode. However, fixing
extended identifiers to include Java/etc-style Unicode escapes should be
relatively easy. In any event, a new preprocessor should be required to
be Unicode-clean, whether or not the base language supports Unicode.

5 - The proposal is, I think, to support macro expansion without
arguments, but not macros with arguments? This might be difficult to
sell - once the user has macros, they'll want to know why they don't
have arguments. As an implementation note, macros with arguments (in C)
are *very* difficult. The C spec has vast (unintentional?) complexity
for little or no benefit. In general, it would be useful to see a list
of equivalent C functionality with the proposed level of support.

6 - the idea that macro expansion should be supported only inside
conditional inclusion directives is interesting, and might be enough for
the "preprocessing is evil" people (if you also drop the proposal for
file inclusion). It might be difficult to sell to real users, though.

7 - If a preprocessor can mess with your source code, then it must
insert #line directives, or downstream tools won't be able to find
source code line numbers. The base language definition must therefore
allow for #line

8 - #error/#warning are not necessary but, for practical reasons, should
be provided. If you give the user a tool to analyse a set of conditions,
then you also have to supply a way to tell them if they've made an error:

#if complex-condA
...
#elif complex-condB
...
#else
#error "problem - should never reach here, or user didn't define X, etc"
#endif

9 - source file inclusion... why? You suggest it under 'features', but
the thrust of the comments above (persistent state across file
boundaries, etc) argues *against* source file inclusion. I think VHDL
already has this covered - we have no concept of "include files", for
example. Do you have a use case for file inclusion in mind?

10 - I don't really understand your comment about "You can change it
simply by whether you present the code in a single analysis step or as a
series of separate steps". Don't all tools effectively treat files as
compilation units? Or are there tools which apply common state to
multiple files if you do something like "compile a.vhd b.vhd c.vhd"?
Surely they shouldn't?

11 - grave accent??! Horrible. Looks and feels amateurish, for obvious
reasons.

12 - If you define a preprocessor, you'll also have to deal with
traditional preprocessor issues: processing phases, handling comments,
etc. You can't just ignore this - what if you have a #if inside a
multi-line comment?

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