[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.