Re: [sv-bc] Merged LRM review 3.8 - compile/elaboration

Much as I agree with this sentiment, it compromises such
definitions as compile-time constant vs elaboration-time constant.

Gordon Vreugdenhil wrote:
> 
> Generally, I thought that the 3.8 section was quite good.  The
> wording is fairly careful about indicating that compilation
> and elaboration can be intermingled.
> 
> A couple of comments.  First, the following could be a
> bit misleading:
> 
>    Beyond the rules defined for compilation units (see 3.8.1), this
>    standard does not define how implementations should perform
>    compilation and elaboration.
> 
> There are other places in which behavior is specified in
> algorithmic manners.  For example, the rules for upwards name
> resolution really do define a "how".  So do the net resolution
> rules for determining the dominating net type and the rules
> for generate instantiations.  There are likely to be other examples
> if the elab-time assertions come into play.  I assume that
> this comment was addressing just the "file" semantics of compilation
> units, but I think that the reference here is a bit too subtle.
> 
> I think that I'd like to rephrase this a bit and tie it in
> with the subsequent note:
> 
>    NOTE—throughout this standard, the terms compilation, compile and
>    compiler often refer to the combined compilation and elaboration
>    process.
> 
> 
> Perhaps something like the following:
> 
>    Although this standard defines the results of compilation and
>    elaboration, the compilation and elaboration steps are not
>    required to be distinct phases in an implementation.  Throughout
>    this standard the terms compilation, compile and compiler normally
>    refer to the combined compilation and elaboration process.  So,
>    for example, when the standard refers to a "compile time error",
>    an implementation is permitted to report the error at any time prior
>    to the start of simulation.
> 
> The "file" semantics of compilation units really addresses a
> different issue -- that SV normally doesn't care about order
> and context of design unit compilation except in a couple
> of cases.  3.8.1 deals with a context issue; the main ordering
> requirement is in 25.2.1 where it is clearly stated that packages
> must "exist" before their items are referenced.  Perhaps the "exist"
> should be modified there to read "compiled" with a bit of discussion
> that this really does mean "compiled" and not the weaker "compiled or
> elaborated" interleaving that is normally permitted.  In reality this
> gets into library issues and since SV doesn't really have a strong
> library concept, it is difficult to be precise.
> 
> I think that we could address both issues by adding something
> like the following:
> 
>    This standard does not normally specify requirements regarding the
>    order of compilation for design units.  The two exceptions are
>    the rules regarding "compilation units" (see 3.8.1) where
>    actual file boundaries during compilation are significant, and the
>    rules regarding references to package items (see 25.2.1) where
>    the compilation of a package is required to precede references to it.
> 
> Gord


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