Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Steven Sharp (sharp@cadence.com)
Date: Wed Jan 29 2003 - 16:47:18 PST
>From: Michael McNamara <mac@verisity.com>
>Come now. Realtobits is presuambly coded as:
>
>typedef union {
> double d;
> long long l;
>} rtb_u;
>
>long long realtobits( double d ) {
> rtb_u u;
> u.d = d;
> return(u.l);
>}
Not quite. The "bits" are 4-value, so you have to take care of the B-bits.
>All that you could optimize away is the procedure call, which on the
>sparc is the call and the return.
There is no reason to generate a call for this. It can be done inline.
To do this, complete with loads and stores of the values, only requires
6 instructions on the SPARC: 2 loads to load the 2 words of the real,
2 stores to store them in the (non-adjacent) words for the A-bits, and
2 stores to set the B-bits to zero.
For a real-to-real copy, it takes 2 instructions since you can use a
doubleword load and store. Each instruction is presumably slower than
the ones above, since they do more memory cycles.
A 4-instruction difference is swamped by the cost of scheduling the net,
whether it is a wreal or a 64-bit vector.
>However, if you do make this conversion to bits as union part of SV,
>you will must then chose:
>
>1) State that the intermediate bit pattern is undefined and
> implementaion specific,
>
>2) Require the little endian (x86) to do it the big endian (sparc)
>way, making this operation more expensive on x86
>
>3) Require the big endian (sparc) to do it the little endian (x86)
>way, making this operation more expensive on sparc
Yes, it is a bad idea. And I haven't heard any reason yet why a
user needs this.
>-mac (beating a dead horse, and enjoying it enormously... You gave me
>a brief bit of joy, allowing me to program in C again... *sigh* )
Steven Sharp (who has a Verilog compiler)
This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 16:47:53 PST