FW: IEEE1647 balloting issues

From: <darren.galpin@infineon.com>
Date: Tue Feb 22 2011 - 01:18:37 PST

Following on from the telecon, Matan has now come up with some suggestions for two of the issues (many thanks!). Please could you review the suggestions and feed back comments to the reflector.

------------------------------------------------------
Comment #9
[FM] "That section title [4.12.2.2] is unexistent bits. However except for the first sentence, the others seems unrelated to that section. Please move unrelated description to another section"

Suggest we move the two unrelated paragraphs to a more appropriate sub-section, as follows:

Put the second paragraph - which reads -
        "The [high : low] order of the bit extract operator is the opposite of the [low.. high] order of the list extract operator."
as a note at the end of the description under 4.12.2, right before the syntax example.

Put the last paragraph - the one that reads -
        "The bit extract operator has a special behavior in packing. Packing the result of a bit extraction uses the exact size in bits (high - low + 1). The size of the following pack expression is (5-3 + 1)+(i-3 + 1): pack(packing.low, A[5:3], B[i:3])"
under the heading "4.12.2.1 Slice and size of the result" at the end, after the printing example.

------------------------------------------------------
Comment #13:
"At the end of the section 4.4 Ranges, there is that sentence: 'If the scalar type is an enumerated type, it is ordered by the value associated with the integer value of each type item.'
Either:
It seems to me that this sentence does not belong in this section and should be better moved to a section talking about enumeration types.
OR:
if the consequence of this sentence is that you can define a range consisting of enumeration constants
(since those are ordered by their value not by their positionin the declaration), a second sentence should describe this. It is not really clear how to define a range of enumeration values.
Please provide an example
Please clarify this"

The last sentence in section 4.4 reads: "If the scalar type is an enumerated type, it is ordered by the value associated with the integer value of each type item."

Propose to rephrase it as follows:

NOTE - The value items of an enumerated type are ordered according to their integer values rather than their respective order in the type definition, for the purpose of determining range membership. So, for example, if type 'color' is defined thus -
        type color: [red =0, green =2, blue =1]; and variable 'c' is defined thus -
        var c: color[red..green];
the value 'blue' belongs to the generative range of 'c'.
------------------------------------------------------

I have tried contacting Francoise Martinolle directly about issue #7, but have had no feedback. If I hear nothing back by the time we have resolved the above two issues, I propose to go ahead with the reballot marking the above issue as a "disagree".

Cheers,

Darren

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Feb 22 01:19:12 2011

This archive was generated by hypermail 2.1.8 : Tue Feb 22 2011 - 01:19:17 PST