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
- Agenda and process
- IEEE tkwiki site open
- Statements chapter
- 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).
- 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: r1 - 2008-09-25 - 13:34:54 -
TWikiGuest