Re: [vhdl-200x] Modular types

From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Fri Jul 11 2014 - 10:08:14 PDT
On Fri, 2014-07-11 at 18:41 +0200, tgingold@free.fr wrote:
> > But if we are providing boolean and shift operators for the special
> > case of modulo 2**n, then we have to do one of:
> > 
> > 1) restrict modular types to mod 2**n. Prohibits other legitimate
> > uses.
> > IMO : Just No.
> 
> Why not.

Because I have no desire to prohibit legitimate uses of modular types,
such as wrapround counters, where modulus need not be 2**n.

> > 2) Define boolean and shift only for mod 2**n and prohibit for other
> > cases. Ugly irregular language feature. IMO : No.
> 
> That's my preferred choice.  There is no obvious definition of logicals
> and shift operators for not mod 2**n types.  So I suppose nobody would
> use them (and we could revisit this issue at a later revision).
> 
> We have many irregular rules (shift operators are only predefined
> for one-dimensional array of BIT and BOOLEAN); and I fear that
> any definition of shift and logical operator for no mod 2**n would
> be ugly.

Interesting. It's not my first choice, but if the details turn out to be
so ugly, I could be persuaded to support (2).

> > 5) Split modular types into two  : power of two, and other. IMO : too
> > much complexity
> 
> We could split modular types into two using the same syntax (enumerated
> types are also split into two: characters ones and the others).
> No complexity here.
in other words, this option would reduce to (2).
> 
> Strongly in favour of 2) after the Ada experience.

I'm interested : what about the Ada logical operators (there are no
shift operators) on modular types is problematic in practice? 

The semantics struck me as a bit odd, but I presumed that was academic
since I didn't think anyone actually used them! 

Is it a matter of the implementation burden, or are there practical
drawbacks too?

- Brian



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Jul 11 10:09:31 2014

This archive was generated by hypermail 2.1.8 : Fri Jul 11 2014 - 10:09:44 PDT