Subject: [sv-cc] SV-CC minutes for 08/20/03
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Aug 20 2003 - 09:36:30 PDT
---+ SV-CC minutes 08/20/03
---++ Attendee list
* Swapnajit
* Doug Warmke
* Ralph Duncan
* John Amouroux
* Andrzej Litwiniuk
* Joao Geada
* Francoise Martinolle
* Bhassam Tabbara
* Ghassan Khoory
---++ General items
Ralph proposes to accept the meeting minutes of 08/06/03
Johnny seconds
Face-to-Face SV 3.1a meeting scheduled for 09/18/03.
Donor companies must give a short presentation of their
donations at that meeting. The deadline will be extended
to 09/18/03 to coincide with the meeting.
Face-to-Face SV-CC meeting.
Swapnajit says agenda still isn't defined, nor is date.
(I think...)
---++ Andrzej's proposal on removing support for multi-D open arrays
Andrzej gives a brief overview of the proposal, similar
to the email. Expresses slight doubt about if the restrictions
given in proposal are a good idea, but likes uniformity with
native SV "unsized" (ie open) arrays.
Doug doesn't think that the gain (uniformity of DPI w SV arrays)
might be worth the price (sacrificing generic programming ability
with all arrays).
Joao continues that open arrays permit C code to "mimic" SV code,
in terms of the ability to call the same functions with arbitrary
sized arrays (of the correct type, of course).
Andrzej mentions that the co-existence of abstract access together
with direct access in the DPI was roundly criticized in the
SV3.1 dissenting vote explanation. His proposal will get
rid of the main complex abstract access mechanism.
Joao mentions that this proposal will simplify implementation
quite a bit, as well as simplify the LRM explanatory sections
as well as the svdpi.h header file. So there is quite a bit
to be gained by it.
Andrzej doesn't have a clear opinion on this issue, sees
arguments for both possible outcomes.
Joao's opinion is that there is "no problem to solve in
the first place". The only slight issue is that it is
easy to confuse open arrays with dynamic arrays due to
syntax notation. But in fact they are very different
features, intended for very different purposes.
This might be making a mountain out of a molehill.
Doug says that in the absence of very strong opinions either
way here, maybe we should err on the side of conservatism
and leave the LRM unchanged.
Swapnajit agrees, stating that such large deletions would
have to be done very carefully, in order to ensure consistency.
Andrzej withdraws proposal after this, and Swapnajit concurs.
---++ Further details in Andrzej's proposal regarding BNF troubles
Non-terminal "variable_dimension" in Sec 2.5, Declaration Ranges
has problem. This only allows one []. Problems when composing
sequences of sized and unsized dimensions.
Solutions: Get rid of dpi_dimension. Introduce a new non-terminal
called "unsized_dimension", which is simplified to include only [].
[Doug just noticed that all these steps are included in Andrzej's
proposal email, in the area called "I propose the following
changes in Section A.2.5, Declaration Ranges"]
Next steps are to vote on the changes, we will do it next meeting.
Andrzej/Joao to resend the proposal, minus the multi-dimensional
array restrictions. That way we are crystal clear on what we
are voting.
Meetings minutes taken by Doug Warmke
This archive was generated by hypermail 2b28 : Wed Aug 20 2003 - 09:38:05 PDT