RE: [sv-ec] streaming operator unpack operation

First, my apologies to Kapil for the original very
brief reply - I was very short of time then.

> I assume you refer to the following sentence:
>
> "If the source expression contains more bits than are
> needed, the appropriate number of bits shall be consumed
> from its left (most significant) end."

That's exactly what I meant.

> Then I think the example is misleading:
>
>  {>>{ a, b, c }} = 96'b1; // OK: unpack a = 0, b = 0, c = 1
>  {>>{ a, b, c }} = 100'b1; // OK: unpack as above (4 bits unread)
>
> "unpack as above" implies that a, b, and c receive the
> same values as in the previous example. If the unpacking
> is from the left end, that will not be true.
> c will get 0, not 1.

You are of course correct.  I obviously missed this when
writing 1707, and so did we all when reviewing it.

I know that the left-justify specification is strange, but
it is already mandated for packing in the existing Draft 4
text:

   The result of the pack operation can be assigned 
   directly to any bit-stream type variable. If the 
   left-hand side represents a fixed-size variable 
   and the stream is larger than the variable, an 
   error will be generated. If the variable is larger 
   than the stream, the stream is left-justified 
   and zero-filled on the right.

And it seems absurd for packing and unpacking not to
be symmetrical in this respect.  If you pack 
something and then immediately unpack it again with
the complementary assignment (or vice versa) you 
surely should expect bits to end up in the same
places they originally were.

Personally I think the left-justify semantics is bizarre,
but I didn't want to change what was already there.

I'll raise a Mantis to change the example.
-- 
Jonathan Bromley


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