Re: EXTERNAL: Re: [vhdl-200x] Update to proposal for arbitrary integers

On Tue, 2014-10-28 at 11:49 +0800, Daniel Kho wrote:
> Jim, YG, all,
> 
> Great. When I was reading through Implicit Numeric Conversions
> proposal, it wasn't very clear to me regarding how meta-values will be
> handled.
> 
> 
> If the ?? operator uses something like the to_integer_or_die()
> function, I will support it.

> However, the only catch with this approach is that this only works
> around the problems, but not fix them. We still potentially run into
> things like how we want to be able to display meta-valued integers in
> a meaningful way in a simulator (for example).

The only logical and reasonably efficient way of adding a metavalue to
(today's 32-bit) integer would be -2**31 (16#80000000). Repurposing this
value to mean NAN would (as an IMO attractive side effect) make the
Integer range symmetric around 0.

Now I have a dim recollection of some mid-1990s tools including an early
Modelsim, Dave Pellerin's simulator (PeakHDL? EasyHDL?) and Autologic
(precursor to Leonardo synthesis tool). I remember some mismatches
between them and I *think* one of the simulation tools choked on -2**31.

My conclusion at the time was that both were legal because the integer
range was only guaranteed to include -2**31 + 1. But I was a little
surprised that the nominally more rigorous Modelsim was actually more
lenient here. (More lenient than which other tool, I cannot recall).

No doubt if we were to try and "restore" -2**31 as outside the valid
range of ordinary integers, all kinds of things would break. And
reworking integer operators to propagate NAN would be slow and
inefficient. (Except unary '-', of course). But if we can overload
operations on new integer types, ... might this allow NaN propagation
where they are used? 

Mixed arithmetic would presumably follow integer rules for efficiency,
unless integers were explicitly converted to the new type (or implicitly
via ?? where the visibility rules allow, i.e ?? is unambiguous). That
would make writing code to propagate NAN tedious and users would want to
restrict its extent : long enough to see the red lines, short enough to
keep the slow code small, e.g. detect a NAN read from memory when it
hits the instruction decoder.

I do not believe I am *recommending* this suggestion, but raising it for
discussion as there does seem to be some demand for integer NAN.

- Brian




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