RE: [vhdl-200x] conditional compilation proposal

From: Higgs, Chris <Chris.Higgs@detica.com>
Date: Tue Aug 16 2011 - 07:42:14 PDT

Evan,

Our task is change the language to facilitate user requirements. If
users are generating code or scripting pre-processors to work around
some language deficiency, we should tackle the deficiency, not provide a
standard mechanism for working around them! Type generics are a prime
example of a welcome language change which obsoletes some of the
code-generation tools used in my organisation.

What is the purpose of conditional compilation? Surely it's to
optionally select compile paths, which is essentially what generate
does. The caveat (as you point out) that the code must be syntactically
correct, however this is not a bad thing (see my comment on the twiki
page). One of VHDL's strengths is that as much as possible it enforces
correctness at compile time.

If you have code which you're never planning on compiling (#if 0) then
there's no need for conditional compilation as you're not going to
conditionally compile it. Isn't commenting out code in this case (or
removing it completely) preferable?

For other cases (#if _SOME_CONDITIONAL_FEATURE_) the generate should be
used. If there is functionality not possible using generate then that is
the issue we should address. Adding an entire pre-processing stage to
mimic #if 0 sounds rather extreme.

Thanks,

Chris

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Evan Lavelle
Sent: 16 August 2011 15:08
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] conditional compilation proposal

I don't personally agree with this. It's not our problem if users write
ugly code. They've got a 30-year-old language, and they already do this,

all the time, without our help. And they've spent the best part of 30
years asking for a pre-processor. A pre-processor doesn't break the
language grammar, if it's defined as just that - a pre-processor with a
separate grammar. It should have no impact at all on the main language
except for the requirement to handle line directives.

A couple of people have suggested an in-language way to handle
conditional compilation. My own view is that this is not practical in
many cases, and conditional inclusion pretty much has to be handled in a

separate pre-processing text translation phase. I'd really like to hear
from someone else who has actually written compilers what they think
about this. The basic idea is simple. If the user's code is broken in
between two preprocessor directives, then you simply can't carry out any

meaningful analysis on the text stream between those two points; the
compiler will just error out. This is exactly the problem that generate
has, and the reason that the LRM doesn't allow bad code in a generate.
That's why this is done as a separate phase - the pre-processor is much
simpler, it only has to search for known directives, and it can simply
ignore the code in between. In practice, there are some sorts of code
that will catch out a preprocessor, but they're not significant.

-Evan

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Please consider the environment before printing this email.
 
This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately.
 
Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. 
 
The contents of this email may relate to dealings with other companies under the control of BAE Systems plc details of which can be found at http://www.baesystems.com/Businesses/index.htm.
 
Detica Limited is a BAE Systems company trading as BAE Systems Detica.
Detica Limited is registered in England and Wales under No: 1337451.
Registered office: Surrey Research Park, Guildford, Surrey, GU2 7YP, England.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Aug 16 07:44:48 2011

This archive was generated by hypermail 2.1.8 : Tue Aug 16 2011 - 07:45:21 PDT