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

Le 2014-07-24 21:36, Jones, Andy D a écrit :
> Function modular8(driven_values: integer_vector) return integer is
> Begin
>  Assert driven_values'length = 1; -- do not allow multiple drivers
>  Return driven_values(driven_values'left) mod 8;
> End function modular8;

"mod" is the correct operator, however it is often implemented with 
*slow* code.
In pathologic cases, any use of the modular type would become 
ridiculously slow and void
certain expected benefits.

I know it's a matter of implementation but we can help a bit there,
for example with defining the special case of power-of-two modulars,
where the "mod" operator is just a AND, which should NOT require
a function call, and is obvious to inline/optimise, so it's almost
transparent.

Non-power-of-twos would use the slower modulo operator.


We could also specify that modular variables always store a "clean",
bound-checked value. This is interesting because in this case,
we can skip the mod operator if the base of the driver is equal
or less than the result's base.


Another question :
How do we define the size of a modular ?

In the proposal I've seen, the base is given as an integer.
However we don't want to arbitrarily limit this size, which is usually
32 bits. Yet 64, 128 or 256-bits registers are in use in the wild.
And i find it ridiculous to write "modular(18446744073709551616)"
when I want 64 bits. "modular(2**64)" does not solve the problem
because of limits on 32 bits platforms, or whatever size, and the pow() 
function
is a crazy overkill (and i don't even mention doing a "mod()")

This leads me to this weird idea (that just popped up):
let's have 2 versions or types, one dedicated to "powers-of-twos",
for example called "binary" or "bits" and accepting an integer that 
indicates
the _number_ of bits. The other would be the "modular" type, where
the integer is the base, directly used for the modulo operator,
32-bits friendly. This would also "solve" the issue I raise
in the first part of the message, about the different and
optimal processing of the mod operator.

It's not a good thing to split the specification but I realise
that there is at least one conflicting constraint :
not limit the base while still using integers.
Is there a better solution, at least for the declaration ?

> Andy D Jones
yg

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