[sv-bc] RE: [sv-ec] Mantis 1067 proposal uploaded

Hi,

I agree that 7.4.6 should tell the full story, for both packed and unpacked arrays, and that 11.5.x can mostly reference 7.4.6, being just a special case. That is assuming that 11.5.1 and 11.5.2 should even survive. Also see Mantis 2423. I think they should just be merged into 7.4.6. The terms 'bit-select' and 'part-select' are used many times before being defined in 11.5.1. Discussing them earlier would reduce that problem also.

The case of a part-select being partly out of bounds does need to be described somewhere.

The current situation, where the same information is described multiple times, leads to inconsistencies, especially where the texts were different at different times.

In contrast to what you wrote in rev A of the proposal, I don't think it would be 'unreasonably disruptive' to move Table 7-1.

Regards,
Shalom

> -----Original Message-----
> From: Jonathan Bromley [mailto:jonathanbromley@ymail.com]
> Sent: Monday, March 21, 2011 11:14 PM
> To: Bresticker, Shalom
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] Mantis 1067 proposal uploaded
>
> Shalom
>
> Once again, thanks for your precise review.
>
> Looking more closely at clauses 11.5.1 and 11.5.2, I'm very reluctant
> to
> fiddle with their text any more. They simply don't take into account
> the variety of possibilities now that we have multi-dimensional packed
> and unpacked arrays, packed structs and unions, and 2-state types.
> Rather than trimming the existing text I'm working on a rewrite that
> deals with multi-dimensional arrays properly by appealing to clause 7 -
> I think we all understand what's supposed to happen, but it's pretty
> much impossible to divine it from 11.5 unless you know all the history.
> The result will probably be of more interest to BC than EC.
>
> Currently, clause 7 cheats by referring to 11.5.1 and 11.5.2 (last few
> words of 7.4, just before 7.5). That's the wrong way around; it's 7.4
> that tells the full story, and 11.5.x should merely describe how that
> applies to the denotation of operands in an expression.
>
> Sorry to be grumpy about this, but I'm losing patience with adding yet
> more warts to obsolete text.
>
> Jonathan Bromley
>
>
> On 14/03/2011 13:16, Bresticker, Shalom wrote:
> > I like the proposal, but I have a few comments:
> >
> > 1. Table 7-1 should move from 7.8.6, which is specific to associative
> arrays, to 7.4.6 (Indexing and slicing of arrays), which is general.
> >
> > 2. The proposal distinguishes between unpacked arrays, saying that
> they return the value shown in Table 7-1, and bit-selects/part-selects,
> that return x for 4-state values and 0 for 2-state values. I think the
> wording in the proposal leaves unclarified cases of multiple packed
> dimensions, where there is an x/z or out-of-bounds index in a packed
> dimensions that is not the least significant dimension.
> >
> > 3. If Table 7-1 is going to have special entries for variable-size
> arrays and for fixed-size arrays, then what about structs and unions?
> Table 6-7 does not have special entries for arrays.
> >
> > 4. In 7.10.1, the proposal changes "with X's or Z's" to "has one or
> more X or Z bits". The latter should be colored blue.
> >
> > 5. 11.5.1 contains, "or the bit-select is x or z". This should
> probably be changed to "or any bit of the bit-select is x or z", to be
> more precise and more consistent with other places. This paragraph,
> describing bit-selects, should also say what happens if such a bit-
> select is written as well as read.
> >
> > 6. There is also another paragraph in 11.5.1 that needs to be
> modified:
> >
> > "A part-select that addresses a range of bits that are completely out
> of the address bounds of the vector, packed array, packed structure,
> parameter or concatenation, or a part-select that is x or z shall yield
> the value x when read and shall have no effect on the data stored when
> written. Part-selects that are partially out of range shall, when read,
> return x for the bits that are out of range and shall, when written,
> only affect the bits that are in range."
> >
> > 7. Some changes in the proposal delete the word "address", as in
> 11.5.1. In 11.5.2, the word remains. Is that deliberate?
> >
> > 8. 7.9.11 says, "If a default value is specified, then reading a
> nonexistent element shall yield the specified default value, and no
> warning shall be issued. Otherwise, the default initial value as
> described in Table 7-1 shall be returned."
> >
> > However, Table 7-1 does not describe default initial values,
> certainly not after this proposal.
> >
> > Regards,
> > Shalom
> >
> >> -----Original Message-----
> >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> >> Jonathan Bromley
> >> Sent: Monday, March 14, 2011 2:01 AM
> >> To: sv-ec@eda.org
> >> Subject: [sv-ec] Mantis 1067 proposal uploaded
> >>
> >> hi EC,
> >>
> >> I've uploaded a draft proposal for 1067 (LRM consistency issues
> >> regarding access to nonexistent array elements). There are a
> >> couple of non-trivial issues involved and I'd be grateful if
> >> we could take a look at it soon.
> >>
> >> I had intended to do this a long while ago, but vacation and
> >> DVCon preparation got in the way. It may be better to delay
> >> discussion to the March-28 meeting to give people time to look
> >> at it more carefully.
> >>
> >> Thanks
> >> --
> >> Jonathan Bromley
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
> >

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.