Phone Conference P1450.3 Working Group
Thursday, Oct 27, 2005 - 10:00-10:30 Pacific Time
- review current TRC proposals
(under the stilusers website)
- review current D10 TRC draft
Nothing under discussion or presentation for this meeting was identified as being proprietary or restricted.
Started Reviewing Dan's TRC D4032 spec, in combination with reviewing
the D10 draft.
Tony opened the discussion at the bottom of the file, in SystemCharacteristics. Dan identified that he needs multiple NumberModules blocks inside SystemCharacteristics, or perhaps a NumberModules statement inside the SignalCharacteristics, to support the ability to identify multiple modules with different functionality. After much confusion, deferred this discussion for closure at the face-to-face meeting at ITC.
Proposal to move MaxSignals into SignalCharacteristics, if I caught the request correctly, which was accepted.
Long discussion about using the number .499 in expressions at the top of this file, to force desired rounding behavior.
Pure syntax issue with the Spec block in this example, missing Category block or references.
Discussion about moving *Characteristics statements from the SignalCharacteristics block and putting them into the higher-level SystemCharacteristics level. What is the meaning of "module" here? Are the modules associated with "Signal" operations, or should these options be placed at the higher-level "System" category?
Decision is to support these statements at BOTH levels - SignalCharacteristics and SystemCharacteristics. We have to resolve the situation of multiple occurances in this context, but this allows common definitions across an architecture ("system") to be defined once and not require repeating the definitions at lower levels.
Issue with the CoreUsageReady Yes|No statement.... What does this mean? Intent: you support the rules defined in dot6. There is a problem with this statement, because STIL writers who write a legal subset of dot6 constructs can say "yes" here (and there is a subset of dot0 that is legal under dot6), however STIL readers would need to support the entire set of dot6 constructs to say "yes". A STIL test may specify "yes" because it's pattern constructs are properly subsetted, yet not use the additional constructs defined in dot6 - but a STIL reader would interpret this "yes" to be outside the context of support if it does not support the "P" statement. This conflict in what is contained vs. what is supported, makes this statement of little use as currently defined. The real issue is: do the patterns contain or not contain the additional "P" statement, and (separate issue) are the patterns constructed in a dot6-compliant fashion?
This opened the discussion on subset support. Do we attempt to document language subsets as part of this spec, and then use a subset statement to identify the supported constructs by a reader, and the constructs generated by a writer? This is an open issue at this time, with a general interest in attempting to do this.
Tony identified that several statements present inside PatternCharacteristics, might be better placed inside the Instructioncharacteristics block. Macro and ProcedureCall statements should move under this block, other statements under review.
The VectorCount statement was discussed in this context, and proposed to move under the InstructCharacteristics block as well. In addition, in reviewing the D4032 file, several additional statement constraints were identified: only 1 form of the statement should be allowed; if the relationship is 1:1 then either form is allowed (they are equivalent) but neither is necessary as this is the default relationship.
Next meeting at ITC. Location is still being finalized. Current opportunity is at TEL, which is significantly closer to the convention center, but still looking for an adjacent location to the convention
Meeting adjourned 11:30 PDT.
Date: Next meeting Monday, Nov 7,
Time: 10:00 to 11:30 Pacific time
AI-1: Tony - update D10 with changes from 9/15 and 9/29
AI-2: Tony - put subset info into