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

Having been following the discussions on this topic, I thought it about time to 
chip in.

I'm not sure if a modular type should be restricted to just natural numbers but 
am happy to go with that for now.

I am interested in modular types to generate counters in RTL and I definitely 
don't want to restrict them to powers of 2.

It feels like we're so close to being able to implement them now and generate a 
package of overloaded subprograms.

But as Andy pointed out, it's getting hold of the subtype of the actual from 
within the subprogram that is the problem.

So we can generate a modular integer type:

    type MOD_NATURAL is 0 to NATURAL'high - 1;

and the modulus for this is the range length - NATURAL'high.

We can then generate subtypes:

    subtype MOD9_NATURAL is MOD_NATURAL range 2 to 11;

with a modulus for this being the subtype range length - 11 - 2 + 1 = 10.

We can then create a function to return the modulus of the subtype using:

    'subtype'high - 'subtype'low + 1

or rather we can't at present because we can't get this from the actual part of 
the interface element.

So my proposal is a new predefined attribute 'actual' to be used with the subtype:

    'actual'subtype'high - 'actual'subtype'low + 1

A simple syntax addition but quite a difference for compiling subprograms (and 
maybe entities?)

The modulus function would then be able to get the actual's subtype information 
when it is instantiated during elaboration and we would then be able to generate 
all the overloaded modulo arithmetic functions.

Now I'm sure there's going to be lots of reasons why this can't be done.

Brent.



On 27/06/2014 21:52, Brian Drummond wrote:
> On Fri, 2014-06-27 at 19:21 +0000, Jones, Andy D wrote:
>> Brian,
>>
>> It is no more, and no less, true in Ada and VHDL.
> [snip]
>> INTEGER does not "inherit" UNIVERSAL_INTEGER operators.
>> Per the LRM, as soon as I define a new type with an integer range,
>> I automatically get the operators and subprograms that are defined
>> for UNIVERSAL_INTEGER, implicitly redefined, exclusively for my type.
> Thank you for correcting my sloppy wording.
>
>> I do not get implicitly defined operators and subprograms that are
>> compatible between my type and INTEGER, and I do not get implicit
>> compatibility with operators defined (implicitly or explicitly)
>> for type INTEGER! I have to define those myself.
> Right, and that was what I wasn't getting. As I thought, defining a
> modular type automatically defines operators on the type itself.
>
> But if I now understand, your objection is that interoperation with
> other types (such as Integer) requires either explicit conversions (with
> Tristan's caveats about their semantics) or the user to define
> overloaded operators such as those between numeric_std and integer.
>
> If such operations were automatically defined for us, that would breach
> type safety. And as Tristan points out, there are problems pressing the
> resolution mechanism into service to help.
>
> Perhaps as an alternative, the standard library could provide a generic
> package, accepting two numeric types, providing the set of operators
> required to interoperate between them. Then having declared a new type,
> I can choose either to maintain type safety, or instantiate this package
> and relax type safety.
>
>> This is also why we have subtypes, rather than just defining new types with
>> different ranges, because we want compatibility with the infrastructure
>> already defined for the base type.
> Now that raises a separate question : what is the meaning of a subtype
> of a modular type? It is compatible with its base type, but does it
> retain the original modulus or is that adjusted to the subtype range?
>
> I have not investigated what Ada does here. (I think it has to retain
> the original modulus, and wrap to 0, both values possibly being out of
> the subtype's range)
>
>> The question is, do we want a new type, with its own, duplicative infrastructure,
>>   or do we want a way to use INTEGERs with an automatic, modulo behavior?
> Remaining close to the original language where practical is also the Ada
> way. Yet modular types were added in 1995, and the ramifications don't
> seem to have been too serious. It might be an easier change than
> significantly reworking the syntax of existing Integers without breaking
> anything.
>
> - Brian
>
>> Before we run off and change the language, let's see if we can get what we want easily enough with the existing language. That's the VHDL way, not the SystemVerilog way.
>>
>> Andy D Jones
>> Electrical Engineering
>> Lockheed Martin Missiles and Fire Control
>> Dallas TX
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Brian Drummond
>> Sent: Thursday, June 26, 2014 4:03 PM
>> To: vhdl-200x@eda.org
>> Subject: EXTERNAL: Re: [vhdl-200x] Modular types
>>
>> On Thu, 2014-06-26 at 20:23 +0000, Jones, Andy D wrote:
>>> I think we're in a pickle with a modular type, since operators would have to be declared for every different type declared..
>> If we're following the Ada model, surely this is no more true than when we declare a new integer type. As a new Integer inherits the operators on Universal_Integer, modular types inherit their own set of operators.
>>
>> Where do resolution functions come into this at all?
>>
>> Or perhaps I am misunderstanding in a big way...
>>
>> - Brian
>>
>>
>>
>> --
>> This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
>>
>>
>
>


-- 

Regards,

         Brent Hayhoe.

Aftonroy Limited                            Telephone: +44 (0)20-8449-1852
135 Lancaster Road,
New Barnet,                                    Mobile: +44 (0)79-6647-2574
Herts., EN4 8AJ,  U.K.                          Email: Brent.Hayhoe@Aftonroy.com

Registered Number: 1744190 England.
Registered Office:

4th Floor, Imperial House,
15 Kingsway,
London, WC2B 6UN, U.K.


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