I don't think this is a good way to implement this, even if it were a good idea. Doing so destroys the modularity of the integer type, making it no longer match the behavior of 32 bit 2's complement arithmetic used by every modern 32 bit CPU. The modularity is important when using 32 bit integer values to extend to 64 bit arithmetic, for example. This would break integer arithmetic for a very marginal if not dubious benefit. On 10/28/2014 7:07 AM, Brian Drummond wrote: > 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 > > > > > -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Oct 28 04:46:59 2014
This archive was generated by hypermail 2.1.8 : Tue Oct 28 2014 - 04:47:18 PDT