RE: [sv-ec] Mantis 1702 - queue concatenation

There is the sentence "Queues and dynamic arrays have the same
assignment and argument passing semantics," which implies that you could
probably assign a queue concatenation to a dynamic array, and a dynamic
array to a queue.

Your proposal would only allow queue concatenations to appear in an
assignment to a queue. That does not mean I'm opposed. I'm just trying
to figure out implications of the proposal.

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Bresticker, Shalom
> Sent: Tuesday, November 13, 2007 12:17 PM
> To: Jonathan Bromley; sv-ec@server.eda.org
> Subject: RE: [sv-ec] Mantis 1702 - queue concatenation
> 
> For background, see http://www.eda-stds.org/sv-ec/hm/3482.html .
> 
> Regards,
> Shalom 
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda.org
> > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Jonathan Bromley
> > Sent: Tuesday, November 13, 2007 12:47 AM
> > To: sv-ec@server.eda.org
> > Subject: [sv-ec] Mantis 1702 - queue concatenation
> > 
> > hi EC
> > 
> > Before I put in the work of preparing a real proposal, I'd 
> value your 
> > feedback on whether the following makes sense for dealing with the 
> > disputed Q={Q,element,...} syntax.  Perhaps I'm being very 
> naive here, 
> > but it seems to me that by restricting the queue-concat 
> syntax to the 
> > RHS of an assignment-like context you can come up with a simple 
> > definition that retains backward compatibility with the de facto 
> > behaviour and with the LRM examples.  I suspect that this 
> restriction 
> > is harmless in practice.
> > 
> > I didn't want to press-gang the '{} syntax into service for this.  
> > There would be so many differences between '{} for queue 
> targets vs. 
> > any other kind of target that I think it's better to stay with {}.
> > And because queues are unpacked, there's no risk of 
> confusion between 
> > this and the traditional concatenation meaning of {} (a normal 
> > concatenation represents a packed object, and can never be 
> assigned to 
> > any unpacked array).
> > 
> > Note that I've tightened up the definition of a "queue"
> > to be an array whose slowest-varying dimension is a queue 
> dimension.  
> > It might be necessary to tweak the wording of
> > 7.11 to match.  I hope this means that the definition is robust 
> > against complicated types like
> >   typedef int silly_queue [$][10][$][][5]; because that's 
> still just a 
> > queue of these:
> >   typedef int silly_item [10][$][][5]; and the rule about what's an 
> > assignment-like context in 10.8 would prohibit the appearance of a 
> > queue-concat as an item in an outer queue-concat.
> > 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > 1) Define "Queue concatenation" syntax 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Add a new subclause 10.9.3 to 10.9 Assignment Patterns, saying 
> > roughly:
> > 
> > Queue concatenations provide a flexible way to write expressions of 
> > queue type.  Queue concatenations may appear as the source 
> expression 
> > in an assignment-like context, and shall not appear in any other 
> > context.
> > The target of such assignment-like context shall be a 
> queue, defined 
> > for the purpose of this clause as an array whose slowest-varying 
> > dimension is a queue dimension.
> > 
> > A queue concatenation shall be written as a comma-separated list of 
> > zero or more items enclosed in braces.  If the list has zero items, 
> > the concatenation shall represent a queue with no elements.  
> > Otherwise, each item shall represent one or more elements of the 
> > resulting queue, interpreted as follows:
> > - an item whose self-determined type is assignment-
> >   compatible with the element type of the target
> >   queue shall represent one element;
> > - an item whose self-determined type is a queue whose
> >   element type is assignment-compatible with the element
> >   type of the target queue shall represent as many
> >   elements as exist in that item;
> > - an item of any other type shall be illegal.
> > The elements thus specified shall be arranged in left- 
> to-right order 
> > to form the resulting queue.
> > 
> > [QUESTION: Do we want other unpacked arrays of appropriate 
> type to be 
> > considered as candidate items? I would say not.
> > Only queues or elements may appear in the concatenation.]
> > 
> > 2) Rewrite 7.11.1
> > ~~~~~~~~~~~~~~~~~
> > Delete the excessively vague sentence "Queues and dynamic 
> arrays have 
> > the same assignment and argument passing semantics."  Add 
> new words to 
> > capture any part of that sentence that needs preserving.  
> > Cross-reference to new
> > 10.9.3 (queue concatenations).  I believe that my proposed text for 
> > 10.9.3 legitimises all the examples in 7.11.1.
> > Examples of more elaborate types could be added if you wish.
> > 
> > 3) BNF
> > ~~~~~~
> > Add BNF for queue concatenation.  The syntax would be 
> identical to the 
> > existing production "concatenation" (A.8.1), but a note 
> would need to 
> > be added referencing 10.9.3.
> > 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 
> > If the consensus is that this is not crazy, I'll write it 
> up properly.
> > 
> > thanks
> > --
> > Jonathan Bromley, Consultant
> > 
> > DOULOS - Developing Design Know-how
> > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
> > 
> > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, 
> Hampshire, BH24 
> > 1AW, UK
> > Tel: +44 (0)1425 471223                   Email: 
> > jonathan.bromley@doulos.com
> > Fax: +44 (0)1425 471573                           Web: 
> > http://www.doulos.com
> > 
> > The contents of this message may contain personal views 
> which are not 
> > the views of Doulos Ltd., unless specifically stated.
> > 
> > --
> > This message has been scanned for viruses and dangerous content by 
> > MailScanner, and is believed to be clean.
> > 
> ---------------------------------------------------------------------
> 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.
> 
---------------------------------------------------------------------
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.