>> Here we have i4 + i4. As long as the + integer operator does not >> overflow, the result can be correctly reduced to mod4 during assignation. >Sorry, but not. The above code is valid VHDL, and will produce an error >during simulation if overflow occurs. I don't think we want to change the > semantic of existing VHDL design. I believe the point was that the overflow does not occur in "+", but in the assignment to another i4. If it had been assigned to an i8, then there would be no overflow. The "+" operator only knows the type (integer) of the operands and result. It does not know the subtypes. I believe there are proposals to allow introspection of a scalar argument for its subtype, but no such luck for the return subtype, though it would be fairly easy to deduce from the context in the above example. However, when the return value is used directly as the actual for an integer argument to mod, as in the earlier example, how would one propose figuring out what subtype to return from "+"? If, on the other hand, we decide that modular is a new type, rather than a subtype of integer, then we have to define operators for every combination of integer and modular arguments and return types, all the while avoiding ambiguity of return type in intermediate expressions. Thus, there is no minimally-invasive solution for modular behavior unless we apply the modular behavior at assignment, which is also where we currently assign bounds checking for subtypes. I get it; yes, modulo at assignment is different that modulo at each operator result. Unfortunately, there aren't any good solutions to the latter. And while for some purposes, modulo at assignment is less useful, it is still extremely useful (more so than what we have now!) And if the modular behavior is going to be applied at assignment, I'd rather have a general solution (expand resolution functions to variables) than a point solution (a language-defined super-subtype). Andy D Jones Electrical Engineering Lockheed Martin Missiles and Fire Control Dallas TX -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Oct 26 18:39:16 2014
This archive was generated by hypermail 2.1.8 : Sun Oct 26 2014 - 18:40:15 PDT