Re: [vhdl-200x] Modular types, alternative solutions

It stands to reason that a 64-bit+ integer would be applied across the
board regardless of the active standard used for each translation unit.
Having mixed size integers of the same type would be a huge can of worms
for any vendor to deal with.

What are the actual issues that could happen with legacy code that expects
a 32-bit integer?. I think it would help if they were explicitly
enumerated. The big one I can think of is the mismatch between simulation
and synthesis where bounds checking is replaced with silent over/underflow
in hardware. Designs dependent on such behavior for synthesized integers
are, in my opinion, broken and I'm not sure the future course of the
language should go out of its way to cater to this sort of legacy code.
This is also an existing problem and not something peculiar to conversion
between mismatched integers. Simulations dependent on termination with
31-bit overflow are likewise broken. What else is there? The rigid signed
semantics and bounds checking of VHDL/Ada are in place to help with the
issue of portability across different integer implementations. There
shouldn't be so much paralysis in implementing larger integers compared to
languages like C without such preconceived expectations for its integral
types.

The Ada standard permits the implementation of additional integer types
with a suggestion to use a naming scheme of the form "Long_Integer".
There's no reason VHDL can't do the same to provide a 64-bit integer. That
would satisfy the users who have to deal with the inconvenience of today's
integer implementations without the fear of breaking legacy code. Synthesis
tools could continue implementing unconstrained integers as 32-bits and
eventually get around to supporting the larger type. All tool vendors would
have an actual "bullet point" to shoot for rather than hiding behind the
permissiveness of the current standard to leave integer alone. I think this
would be the easiest way to move forward while satisfying all existing
players with concern about changes to the size of integer. Even better
would be to permit user defined integer types with a guaranteed 128-bit
minimum range for those who really need it.

--
Kevin Thibedeau

On Thu, Oct 30, 2014 at 5:17 AM, ht-lab <hans64@ht-lab.com> wrote:

> Hi Jim,
>
> On 29/10/2014 18:51, Jim Lewis wrote:
>
>> Ray,
>> Oops.  I was not clear.  I was referring to "very few engineers/companies
>> asked for VHDL2008 and hence the uptake was rather slow".
>>
>
> I think my statement was a bit too simplistic and obviously there are more
> factors playing in the slow uptake of VHDL2008.
>
>
>> I agree, 64 bit integers is not a bug.  Asking for them is not
>> non-compliant with the LRM, however larger than 32 bit would potentially be
>> non-portable.  OTOH,
>>
>
> I guess the non-portability (in general) is not really an issue as users
> can compile modules for different standards. I have seen scripts with both
> -87 and -2008 used on the same project.
>
> Regards,
> Hans.
>
>
>
>> Jim
>>
>>> And the answer from the vendor when asked to incorporate features not in
>>> the LRM is that such changes don't comply with the spec, so it isn't a bug,
>>> nor is it likely to be implements .  BTDT.
>>>
>>> On 10/29/2014 12:42 PM, Jim Lewis wrote:
>>>
>>>> If that is truely the case, then we have a perception issue. Engineers
>>>> simply are not in the practice of having to ask a vendor to implement new
>>>> features of a standard for which the vendor makes a product.   From an
>>>> engineers perspective, having to do that is silly.
>>>>
>>>> So our job is to educate people that if they want the new language
>>>> features, they have to make requests and file bug reports against the tools
>>>>
>>>> Cheers,
>>>> Jim
>>>>
>>>>
>>>
>>>
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>

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