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

On 03/07/2014 02:11, ryan.w.hinton@L-3com.com wrote:
> On Wednesday, July 02, 2014 10:11 AM, Brent Hayhoe wrote:
> ...
>> It feels like we're so close to being able to implement them now and generate
>> a package of overloaded subprograms.
> Several people have pointed out that direct assignment remains a problem even
> if you overload the arithmetic operators appropriately.  That's why Andy
> suggested generalizing resolution functions as a hook into the assignment
> semantics.
I thought that Andy's comments were more to do with the inability of subprograms 
to get hold of the actual's type constraints?

I can see some type conversions which may require reference to the function 
return subtype and this maybe another reason to sort out the problems with this 
proposal:

http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/FunctionsKnowOutputSubtype
> ...
>> 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.
> Is there a technical reason for this?  (Compiler people?)  I know entity
> interface array objects can take their index and element ranges from actuals.
> It seems natural for an unconstrained integer or other discrete type to take
> its range from the actual.  In fact, it seemed natural enough that I wrote a test case to confirm that these attributes *don't* pass through the interface.  This seems like it would cause problems if an out-mode actual object has a(n integer) range constraint and the procedure starts manipulating it.  I guess I don't do this much in practice, but I can certainly imagine it being a problem.
>
> - Ryan
You went down the same route as me in generating test cases to check this out.

It's one of the few places in VHDL where you cannot be specific in want you want 
to do. Hence the 'actual attribute and maybe we should have a 'formal attribute 
to be complete.

Brent.

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