I am in agreement with most of this proposal. However, I feel we are getting confused between defining a modular integer type and its implementation within a compiler. Integers, as a VHDL type, have no comprehension of shift functions or logical functions. These imply vectors, or how we would naturally implement integers. They do have mathematical equivalents, e.g. shift -> 2**(±N) assuming we are mapping to a binary vector such as UNSIGNED. As such they should be added as overloads to the Numeric_Std and Numeric_Bit packages. Now, most explanations of modular types start with the analogy to time - hours, minutes, and seconds and that they are examples of modulo 12 types i.e: 1, 2, 3,....11, 12. and then they very quickly normalize this type to: 0, 1, 2,....10, 11. and then start explaining modular types. In fact there are many (infinite) subtypes of this range length that are of a modulo 12 subtype. So in order to perform the arithmetic in normal INTEGER, we will need to first normalize any modular types and caste to INTEGER: int_object = INTEGER(mod_object - MOD_TYPE'low) ....... or do we??? and then after performing the integer calculation, the resolution function will need to convert it back to its modulo type and reverse-normalize at the assignment point: mod_object = MOD_TYPE(int_object mod MOD_TYPE'length) + MOD_TYPE'low That is my concept of how we should handle modular type arithmetic. Regards, Brent. On 28/07/2014 09:07, Martin.J Thompson wrote: > From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of whygee@f-cpu.org > >> Another question : >> How do we define the size of a modular ? > > My feeling is it should be of a "universal integer". And that we should extend the range of that type - but that's separate proposals: > > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/LongIntegers > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ArbitraryIntegers. > > Cheers, > Martin > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jul 30 22:56:19 2014
This archive was generated by hypermail 2.1.8 : Wed Jul 30 2014 - 22:57:08 PDT