Re: resolved integers (was RE: [vhdl-200x] Update to proposal for arbitrary integers)

On Tue, 2014-10-14 at 14:04 +0000, Martin.J Thompson wrote:
> Thanks Brian, I agree with pretty much everything you've said below.  One niggle - the overhead may 
> not be quite so great as you are only carrying one "resolution bit" per integer, rather than having 
> to resolve each bit individually for an unsigned vector (even though it pretty much always ends up 
> resolved as a whole - I wonder if any simulators are smart enough to optimise that case?)

Yes, the penalty could (should!) be less; some intermediate speed
between numeric_std and integer. 

But then, (for example) today's bit_vector (not slv) can potentially be
implemented as a "packed array of bits" with 32 bits to a word, and run
as fast as native binary operations on "int" types (with necessary
efficiency penalties for bit_vectors >32 or maybe >64 bits). 

Yet simulators typically don't bother, so as Whygee's speed tests
demonstrated, bit_vector speed is similar to std_logic_vector and two
orders of magnitude slower than native "int". Which is partly why we are
talking about adding modular types instead of encouraging a better
implementation of the existing bit_vector (and unsigned_bit) type.

So would they spend the money to achieve that intermediate speed, or
would they map the new feature onto the (working) numeric_std codebase? 
Or, if tool makers weren't working so hard to keep up with the standard,
could they make their existing tools less sub-optimal?

> "Adding out-of-band signalling like this to every integer would add a lot of cost and complexity and execution time penalty to a simulator."
> 
> I'd propose (if I were proposing this extension, which I'm not :) a separate type, so the overhead is not carried by normal ints (much like std_ulogic vs std_logic).

I'd agree with this! But it's still multiplying the entities built into
the language.

I'd rather see the language made cleaner and more general. 

For example, assume this sort of "added value integer" - AV_Integer -
was to be implemented as a record combining the integer value and its
status. Given a clean enough type system and set of abstractions you can
implement it purely as a library, like numeric_std, with a full set of
operators on AV_Integer. ( hypothesising: it's just possible that 2008's
generic packages etc are good enough that we can do this already - I
haven't tried it)

Correcting any niggles in the underlying language prohibiting this, or
making it untidy or unnecessarily verbose would be positive language
changes, rather than adding special cases to cover every need.

Another example of an underlying mechanism might be tagged records and
class-wide types ala Ada-95,2005 and Peter Ashenden's old proposal,
which would allow inheritance and an object-oriented style, but keeping
the base language as small and simple as possible. (Janick Bergeron's
"Writing Testbenches" 2nd ed is quite convincing that inheritance and
programming by extension is valuable in verification)

- Brian



> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Brian Drummond
> Sent: 14 October 2014 14:00
> To: vhdl-200x@eda.org
> Subject: Re: resolved integers (was RE: [vhdl-200x] Update to proposal for arbitrary integers)
> 
> On Tue, 2014-10-14 at 12:09 +0000, Martin.J Thompson wrote:
> > From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On 
> > Behalf Of David Bishop
> > 
> > 
> > 
> > A “NaN” is a very specific value for a floating point number.   An
> > exponent of all “1” (which means infinity) and a fraction which starts
> > with a “1”.     Since all of the bits in an integer are valid, I don’t
> > know how you would do an invalid number.   You can’t just pick one
> > because somebody will need to use it.
> > 
> > 
> > 
> > I agree – if you want an ‘undriven value’, then it has to be separate.
> > The simulator could track it in whatever softwarey way suits, say via 
> > an internal variable with a bit for each resolved integer object which 
> > needs to be tracked.  In synthesis, a resolved integer could an extra 
> > bit to signifiy its “drivenness”.
> 
> We need to think carefully before we add this.
> 
> Adding out-of-band signalling like this to every integer would add a lot of cost and complexity and execution time penalty to a simulator.
> 
> Resolved integers can be modelled using existing numeric_std  "unsigned"
> or "signed" types ... why not use them? 
> 
> Presumably because of the speed penalty.
> 
> Which arises - at least in part - because of the out of band signalling required for resolution, "undriven values" and presumably we would also need some expression of "X"  unknown or conflicted resolution, and possibly don't cares.
> 
> I'm not doubting that this proposal adds some value. 
> 
> But does it add enough to justify a new level of complexity somewhere between full numeric_std and the simplicity and thus performance of native 32-bit or 64-bit integer? Or would it end up costing enough in performance that people would be reluctant to use it?
> 
> I use integers where I don't need this added functionality and numeric_std when I do. 
> 
> I support the "universal_integer" extension because it allows for restricted-range derived types such as the existing 32-bit signed integer, and presumably gives a tool permission to add e.g. 32-bit unsigned integers (as opposed to the current 31-bit natural!) and 64-bit signed or unsigned with efficient implementation. While some tools may choose to support 128 bit or arbitrary width arithmetic I wouldn't expect to see it on a widespread basis soon.
> 
> I support the "modular types" extension allowing boolean and shift operators on a type which is no longer strictly integer (but efficiently implemented using native instructions on typical processors, and easily converted to/from integer)
> 
> But I'm cautious about this because it cannot be so efficiently implemented (unlike FP NAN which uses in-band values).
> 
> - Brian
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
> 
> 
> 



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