22 Sept 2008 - Workgroup Meeting Minutes

  • Workgroup: P1778 - Esterel v7 language standardization
  • Location: Teleconference (see Next Meeting to connect)
  • Date: 22 Sept 2008
  • Chair: Gerard Berry
  • Vice Chair: Stephen Edwards
  • Secretary: Sylvan Dissoubray

Attendance

  • Present: Gerard, Marc Perreaut, Sylvan, Ramesh, Eric, Charles, Luigi, Klaus, Raphael, Stephen, Mike, Marc Duranton, Shyam
  • Excused: Claus, Jean-Philippe, Badr
  • See Attendance Record for meetings participation history

Agenda

  1. Agenda and process
  2. IEEE tkwiki site open
  3. Statements chapter
  4. Next meetings

Process

  • Start: Chair declares the meeting open at 4:06
  • Agenda: The agenda is approved by participants
  • Minutes: No objections about last meeting minutes -- they are approved
  • Patents: No new item . The page IEEE Patent Policy holds the call for patent, and workgroup status.

Technical topics

Brief summary of discussion, pros and cons, and conclusions

Statements chapter comments

  • Comments were contributed on the wiki and on annotated pdf by the workgroup (Claus, Ramesh, Luigi, Shyam, ...). All reviewed and discussed during the meeting.

  • General impressions
    • EB: quite clear now.
    • SE: some imprecisions need to be fixed.
    • MD: comment about tags. semantics is good.
    • SE: semantics at the end ? GB: tradeoff, big chapter this way makes it more readable. Too many examples? (with default, without default).
    • MK: new presentation is nice, in general.

  • Tags: explicit toplevel section, the program conceptually has tags, etc. Move 12.1.4 after 12.2 (belongs to semantics).

  • KS: 12.1.5 Too detailed?

  • MD explain synchronous earlier than chapter 12 ? Think about what to define in the introductive overview and definitions

  • Semicolon Nobody wants semicolon as separator, everybody wants it to be a terminator. Agreed.

  • Brackets must be in syntax rules

  • Traps are necessarily outside parallel add a note

  • for dopar: shall be positive. If not, it is either a compile-time or run-time error. Better decide what kind of error. Also possible to decide that if not positive then is considered as nothing This seems a better option. Semantics is static expansion, compile-time or run-time: whichever (implementation choice). This question is related to to static_if and static_for. static_for and for (not expanded). The interest is because of the need to generate linear VHDL wrt Esterel source size.
    • SE: static statements are appreciated (discussed in C++). Just syntactic concern.
    • do seq has been asked. Only way seems to be static.
    • static before expression or before statement? nested expressions too complex.

  • repeat, positive or not. mandatory for dependency analysis. repeat until would be clearer. Think about index usage inside the repeat
    • similar to static discussion

  • clarify delayed suspend defnition

  • concurrent traps (trap T1, T2 in) have been removed to simplify the statements. No practical objection.

  • Discussion about static instructions:
    • A static instruction, e.g. static if or static for has the same semantics as the non-static form, expect that it requires the intruction to be performed statically, i.e. at compile-time.
    • The static if instruction is a clean form of #ifdef and makes static run module recursion possible.
    • The static for makes it possible for the user to specify whether the for loop must be expanded at compile-time. The static for is useful to handle carry array dependencies over modules under for loops, which cause static cycles without the compile-time for loop expansion. There are several possible syntaxes:

static_if e then
...
static if e then
...
if_static e then
...
if static e then
...

  • Propositions for while-do and do-while instructions
trap done in
  loop
    if e then exit done;
    p
  end loop
end trap

do
  p
while e
<=>
trap done in
  loop
    p;
    if e then exit done
  end loop
end trap

To be experimented before. We have experiment of "nice" instructions that have been added but never proved to be useful.

  • Constructiveness and causality issues. The standard will say nothing about that. Compiler may have different point of views and accept different programs. The important point is that when a program is accepted by two different compilers, then it does the same.

Motions and actions items with name and due date

Adjournment and Next meeting date

  • Next meeting will be about signals. Monday 20th October - 4 PM Paris time
  • Meeting is closed at 5:45 PM.
Topic revision: r4 - 2008-09-25 - 13:34:54 - SylvanDissoubray
 
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback