[sv-bc] RE: [sv-ec] streaming operator unpack operation

Hi Surya,

 

"If the left-hand side represents a fixed-size variable and the stream
is larger than the variable, an error will be generated."



This statement is made w.r.t. the "pack operation", while the example
you refer to is that of "unpack operation". So I guess you are mixing up
two different things. There is another example in the LRM which
corresponds to this statement:

 

int j = {>>{ a, b, c }}; // error: j is 32 bits < 96 bits

 

Thanks,

Kapil

 

 

________________________________

From: Surya Pratik Saha [mailto:spsaha@cal.interrasystems.com] 
Sent: Tuesday, March 11, 2008 12:42 PM
To: Kapil Kaushik
Cc: Jonathan Bromley; Bresticker, Shalom; sv-ec@eda.org; sv-bc@eda.org
Subject: Re: [sv-ec] streaming operator unpack operation

 

Hi,
LRM once states:
"If the left-hand side represents a fixed-size variable and the stream
is larger than the variable, an error will be generated."

And then there is an e.g:



{>>{ a, b, c }} = 100'b1;
 
If we go by the text, then the e.g. is wrong.
 
They are contradictory to each other. Either of them has to be fixed.
Regards
Surya



-------- Original Message  --------
Subject: Re:[sv-ec] streaming operator unpack operation
From: Kapil Kaushik <kkapil@magma-da.com> <mailto:kkapil@magma-da.com> 
To: Jonathan Bromley <jonathan.bromley@doulos.com>
<mailto:jonathan.bromley@doulos.com> , Bresticker, Shalom
<shalom.bresticker@intel.com> <mailto:shalom.bresticker@intel.com> ,
sv-ec@eda.org
Date: Tuesday, March 11, 2008 12:17:57 PM



Hi Jonathan/Shalom,
 
Thanks for your detailed explanation of the things. 
 
I am just restating what you said for my own clarity. Please point me
out if I am wrong.
{(operator){a, b, c}} = 100'b1, where "operator" = ">>" or "<<"
is equivalent to taking the left 96 bits and streaming them according to
the normal streaming rules, and it does not depend upon the "operator"
as to which bits of RHS will be truncated.
 
So for both the cases below:
{>>{ a, b, c }} = 100'b1;
{<<{ a, b, c }} = 100'b1;
 
We will have a = 0, b = 0, and c = 0.
 
Thanks,
Kapil
 
-----Original Message-----
From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
Sent: Tuesday, March 11, 2008 11:17 AM
To: Bresticker, Shalom; Kapil Kaushik; sv-ec@eda.org
Subject: 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.
  

 


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