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.