Subject: Re: [sv-ec] Re: [sv-bc] Packed arrays
From: Steven Sharp (sharp@cadence.com)
Date: Wed Jan 29 2003 - 14:47:27 PST
>Date: Wed, 29 Jan 2003 13:48:35 -0800 (PST)
>From: "Kevin Cameron x3251" <Kevin.Cameron@nsc.com>
>I meant "deprecate" as in "you are advised not to use this", taking
>anything out of the language is always painful. I'll be doing the
>same for "wreal" when we combine SV and AMS.
That is not what deprecate means in this context. The clumsiness of
the older approach will probably be enough to discourage most people
from using it once they have something more convenient.
BTW, if SV has the proper type system, backward compatibility with
wreal could be gotten with a typedef.
>You would only have to do that with packed structs/unions, and the
>overhead difference is likely to be marginal.
But since the storage layout for a floating point value in a packed
struct/union would be different than normal, your idea of being able
to define all data types in terms of packed structs still wouldn't
work. All you could do is define an object that works like a native
real, but slower and with a different layout. It wouldn't actually
be a definition of the native real type used for real variables that
weren't in a packed struct.
>Using $rtb/$btr is definitely slower regardless of bit order than
>using wreal or a shared variable.
It is slower than a wreal, but not greatly so. Why would you think that
it was? Aside from the presence of the B-bits in the 64-bit vector form,
there is very little difference in the implementation. It is certainly
less impact than having to rearrange the bytes or words into a different
order when accessing reals out of a packed struct.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2b28 : Wed Jan 29 2003 - 14:48:16 PST