Let's separate issues regarding the range of integers from modular integers, shall we? They are orthogonal issues. You make some interesting claims about the heavy-weightedness of resolution functions. Seems like most designs use resolved types an awful lot without too much trouble, so what's so heavy about applying resolution functions to variables in the same way they are applied to signals (including ports and parameters of signal kind, to answer one of your questions)? Does the compiler "pass" a bounds checking function for subtyped parameters to subprograms now? What about a resolution function for signal parameters on a subprogram? All of this is fairly well understood at the compiler level already, so what's the problem? In fact, if anything, figuring out, and then passing, the expected subtype of a return value for an intermediate expression to a function would be way more difficult to implement than a simple extension of an existing language mechanism. While all universal_integer types inherit the standard operators, they do not inherit operators that will interoperate between different universal integer types. If we define something as type xyz is (range| modulo | saturate) a to b, then we automatically get new standard operators between arguments of type xyz (and returning the same type!), but not between xyz and some other type qrs. Thus the need to explicitly define operators that work with L : xyz and R: qrs (and for the reverse!). Furthermore, if xyz and qrs have different modulus, what/which return type to use for the operator? What happens when I want to add a modulo type to a saturate type; is the result a modulo, or a saturated , and with which/what range? These and many more issues are why using types for this functionality is a non-starter, unless we completely re-define what "type" means, yet in a backward-compatible way. That leaves resolved or unresolved subtypes. The latter would need to be communicated to functions (to answer the same result subtype questions as above), for which we have no backward compatible mechanism. The former (resolved subtypes) already have a well-defined (if not fully employed) use model that is reasonably expandable to variables. Perhaps using a resolved_subtype'() mechanism could be used to accomplish saturation or modular behavior for intermediate sub-expressions by employing the resolution function associated with the resolved subtype? Andy D Jones Electrical Engineering Lockheed Martin Missiles and Fire Control Dallas TX -----Original Message----- From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Tristan Gingold Sent: Tuesday, October 28, 2014 1:28 AM To: vhdl-200x@eda.org Subject: EXTERNAL: Re: [vhdl-200x] A compromise about modular type, boolean operations, integers... [Might be a duplicate] > 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. No, we don't have to define operators for every combination of integer and modular arguments (this is simply not possible as the analyser doesn't know all the integer and modular types). We need to define operators for each type. Std.Standard defines real and integer, but no combined operators (well except for "**"). Or simply see how Ada handles modular types. > 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 don't agree with that. Defining a modular type class is minimally invasive. > 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!) Many languages have modular types. See for example C (the unsigned types) and Ada (modular type). I think these solutions are far better than what you propose. Do you realize that with your solution you cannot have a 2**32 modular type ? > 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). That doesn't work well. First, it is not really compatible with the existing language; second you need to have an heavy mechanism to pass resolution function to subprograms; third, you need to define precisely where the assignments are done (are they done when a parameter is passed to a subprogram ?); fourth, I don't see clearly how that would be synthetizable; and finally that's also crippled (you cannot have a 2**32 modular subtype). Tristan. -- 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.Received on Wed Oct 29 20:02:29 2014
This archive was generated by hypermail 2.1.8 : Wed Oct 29 2014 - 20:02:58 PDT