Dmitry, I will not be able to attend as I am in India. If there is a webex/dialin, I will try to attend remotely, although given the nature of my concerns, I very much doubt that a remote discussion will be very effective. Here are some high-level comments on this. I don't think that BC/EC likely needs (or wants) to know about all the assertions specific areas that are in play. For example, in the slides that were posted, the issues related to SAR and AAR are likely not really relevant to the concerns raised in BC/EC. What is of concern (at least to me) are some of the comments on slides 37 and following. I know that the way in which the "loop unrolling" and similar constraints are now being expressed is different, but the fundamental view is still there. Some of the semantics of "sampling", etc. as raised on the slides have not really become much clearer to me either. Some of the special routines (for example those related to enables) for checkers really need to be explained in terms of how they relate to the outer language constructs. Rules regarding force, hierarchical naming, etc. need to be covered. Issues related to freevars (vcd dumping, forcing, coverage, etc) need to be explained, including comments as to what aspects of simulator behavior are vendor defined. One of the slide comments (on slide 10) was that assertions is procedural code is just "syntactic sugaring". There have been various things since then that make me question that. So, if the "syntactic sugar" claim (esp. wrt checkers) is true, why all the new features and complexity? If it isn't true (which I don't think it is), then the different rules need to be carefully laid out. I'd like to have a fairly concise description of the differences in rules for immediate assertions, deferred assertions, concurrent assertions, and assertions in checkers. All in the context of procedural code since that is the main area where things get really messy. If that cannot be summarized concisely and completely, it would make me wonder about the complexity of the resulting language and whether we aren't opening the door to very difficult language compositionality issues in the future. At a high level, I understand that when I've raised point issues that those have eventually (for the most part) been resolved to some extent. My high level concern is that I think that the resulting system is so complex that it is extremely difficult to reason about the language feature interactions and how they will compose in the future. Gord -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Mar 5 21:35:45 2008
This archive was generated by hypermail 2.1.8 : Wed Mar 05 2008 - 21:38:43 PST