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

From: David Koontz <>
Date: Tue Aug 05 2014 - 20:26:22 PDT
On 4 Aug 2014, at 10:18 pm, wrote:

> Le 2014-08-04 09:49, Brian Drummond a écrit :
>> On Mon, 2014-08-04 at 08:03 +0200, wrote:
>>> But you can do such experiment already today (and even with vhdl 87):
>>> declare a record type with one integer element, add declare all the
>>> operations you need: +, -, and, or, ...
>>> No need to perverse an existing feature to do experimentations.
> I would think that this "feature" itself is perverse, but for my own
> personal reasons :-P
> I have not seen it done, it's not a "classic pattern" because usually,
> users try to "stick to the least common denominator" and some tools might
> not even know what a record is.
> it might work with synthesis and the result of the simulation will be "correct"
> with moderate code complexity. However Brian has a point there :
>> I think Whygee's point is that while there are ways of experimenting
>> with the semantics today, using records, what he wants is the
>> performance of native boolean/shift operators on integer-like
>> quantities.
> So, in the case of GHDL, being able to emit "OR"/"AND"/"XOR"/"NOT"/etc. opcodes
> to GCC.
>> My suspicion is that adding modular types natively will get close to the
>> performance gain he wants (compiling down to native machine
>> instructions), but that adding the semantics via heavier tools like
>> resolution functions - or records - might add most of the performance
>> penalty of signals over variables and thus destroy what he wants to
>> accomplish.
> There is that. But... It also overlooks one detail : the functions I request
> are not present, allowed or even remotely "emulable" with VHDL integers.
> I've covered the difficulty of doing basic boolean operations a few years
> ago (for example, shifts with divides and multiplies with powers of two...)
> and the actual result was worse than using std_logic_vector.

You appear to be mixing metaphors where you might actually be performance oriented and not so much implementation method oriented, complaining about performance with respect to std_logic_vector.

I had this big long diatribe on how there's likely room to improve bit_vector predefined operator performance relating to implementation representation to give better performance. That sort of get's cut short by noting the there's only one place in the -2008 standard where the word 'performance' occurs (22.2.8 - VHPI, the last note on page 374).

It would seem that performance is not an issue addressable in the language standard and that trying to strong arm the language definition without tool vendor consensus you're not likely to get the performance you're after by market place language version pressure without demonstrable competitive advantage affecting implementation. We're already seeing vendor standard version uptake
severely lag particular among synthesis vendors, where competitive pressure fuels adoption.

Performance should likely be tool vendor implementation driven.  There's a lot of pressure in someone doing something first as opposed to standardization fiat.

(And implementation improvements might involve packing bit_vectors into native uint or equivalent representations, where bignum sounds like a natural fallout. A bit_vector that can be wholly contained in a single native unsigned integer representation could be as fast as in other languages.  There are ways to maximize std_logic_vector and other user defined type operator performance by implementation representation as well, these tending to be a bit more platform dependent.)

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Aug 5 20:26:55 2014

This archive was generated by hypermail 2.1.8 : Tue Aug 05 2014 - 20:27:54 PDT