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

I think that the most common functional requirements for modular types can
be met by bit_vectors, since in most cases the modulus is a power of 2.

The challenge is that the numeric_bit library is not fast enough.  Tools
need to provide the optimizations described by David.

Peter Flake


-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
David Koontz
Sent: 06 August 2014 04:26
To: VHDL IEEE
Subject: Re: EXTERNAL: Re: [vhdl-200x] RE: Modular types


On 4 Aug 2014, at 10:18 pm, whygee@f-cpu.org wrote:

> Le 2014-08-04 09:49, Brian Drummond a écrit :
>> On Mon, 2014-08-04 at 08:03 +0200, tgingold@free.fr 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.





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