Re: [vhdl-200x] RE: Modular types

On 31/07/2014 07:54, whygee@f-cpu.org wrote:
> Hello,
>
> Le 2014-07-31 07:55, Brent Hayhoe a écrit :
>> 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.
>
> for me it's not confusion, it's also about what goal we are pursuing.
> Trying to make VHDL too abstract can lead to too much inefficiencies.

I do not believe that maintaining the strong typing philosophy and maintaining 
what an integer is, constitutes making VHDL too abstract. And abstraction does 
not necessarily lead to inefficiencies.


>> 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.
>
> But then, what else do you want to map integers too ?
> what other representation might eventually be used in practice ?
> Ternary was briefly experimented with by Russians with no real impact.
> Everybody and their dog use binary.

I'm not arguing for what an integer may or may not be mapped to, but that is for 
the user to decide and why we have UNSIGNED, SIGNED etc.

It is not for the language designer to enforce what mapping(s) should be used, 
that is the user's prerogative.


>> As such they should be added as overloads to the Numeric_Std and
>> Numeric_Bit packages.
>
> Can you elaborate ?
> (no pun intended)

They were(are) the first standardized packages to enable/define vector numerical 
codings with overloaded arithmetic functions.


>> 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.
>
> normalisation is a matter of convention, people are used
> to use "12" for "0"...

But the 'mod' function will not work unless you use a normalized range


>> 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???
>
> the modular type should be stored as a normalised (mod'ed) integer.
> so you don't need to compute the subtraction.

Why? Is a subtraction such a complicated operation?

What gives you the authority to decide that users are only allowed to use 
normalized modular ranges? It makes anything telling the time quite awkward!


> I probably missed discussions about the range of modulo types,
> and I'm not even sure that they are a subtype of integers so do we have a 'low ?

It's on-line here: http://www.eda-twiki.org/vhdl-200x/hm/2242.html


>> 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.
>
> This is the principle, yes.
>
> Now, we wouldn't need modular types if the "pure math integer" approach
> of VHDL was enough. And we must not forget that VHDL is not a math or calculus
> language but a circuit description language, and our circuits are made of bits :-)

We've had many examples of why modular types are useful for circuit design and 
VHDL is not just a circuit design language.

It has always been a very powerful verification language and this lack of 
perception regarding this, is why it gets such bad press against languages like 
SystemC and SystemVerilog.

I'm sure there are users who could make a good justification why VHDL could do 
with more maths embedded in the language.


Regards,

Brent.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.