On 30/10/14 04:02, Jones, Andy D wrote: > Let's separate issues regarding the range of integers from modular integers, shall we? They are orthogonal issues. No, this isn't orthogonal. As long as integers have a range, the issue is present. Don't try to avoid the 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)? Simulators know about std_logic and types based on it. If a signal declared with that types has only one driver, it could simply not call the resolution function. So in practice they are almost not used. Resolution functions are not used at all for parameters. > Does the compiler "pass" a bounds checking function for subtyped > parameters to subprograms now? No. There is nothing like that (bound checking function) in the standard. > What about a resolution function for signal parameters on a subprogram? It can be safely ignored, as it doesn't change the behaviour of a subprogram. > All of this is fairly well > understood at the compiler level already, so what's the problem? They are indeed well understood, so how would they achieve what you expect from them in that proposal ? > 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. Because at many places, the subtype is not known, only the type is. Because for user defined functions, the subtype of a parameter is simply indicated in the parameter declaration. You propose to change that, that would be incompatible. > While all universal_integer types inherit the standard operators, > they do not inherit operators that will interoperate between > different universal integer types. Sorry, that doesn't mean anything. First, there is only one universal_integer type. Second, there is no operator inheritance. > 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. Yes, that's true. This is how vhdl is currently defined. > Thus the need to explicitly define operators that work > with L : xyz and R: qrs (and for the reverse!). No, you don't need that. If you want to operate between different types, you can use type conversion. That's strong typing, and that's how vhdl is currently defined. > 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? The answer is simple: you cannot do that directly. You need to explicitly convert first. That's strong typing. > 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. Sorry, but you are jumping to wrong conclusions. Ada95 has added modular types over Ada83, without redefining what a type is. This is very clean. If we add modular or saturated types, we don't change the typing system. > 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? I don't think that having to qualify each sub-expression is a good design. You haven't answered to the third and fourth point: how would that be synthetisable (ie how a synthetizer would recognize that you are using a saturated or a modular subtype) ? And you haven't clearly defined when these resolution functions are called. I am not that very worried by your proposal: I am almost 100% sure it will completely fail when someone would start to write the changes for the LRM. But better not to spend too much time on incorrect ideas. Regards, Tristan. > -----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 22:02:19 2014
This archive was generated by hypermail 2.1.8 : Wed Oct 29 2014 - 22:03:03 PDT