RE: [vhdl-200x] Logical (and shift) operations on Integers

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of whygee@f-cpu.org
Sent: 01 September 2014 00:03
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Logical (and shift) operations on Integers

>Le 2014-08-29 12:20, Martin.J Thompson a écrit :
>> Hi all,
>> One of the implications of doing this is that it would define a 
>> definite representation for integers which have these operations 
>> applied to them (ie 2-s complement binary).>
>
>I don't think it is a big problem.
>  * Can you name a machine that uses a different number representation ?
>  * if a system uses a different encoding, is it used to handle VHDL ?

That's exactly the point - and FPGA synthesiser might want to use a different representation.  One of the examples given was for an integer of limited range but with large numbers (159 to 163 for example) - could be nicely represented by 3 bits by a sufficiently clever synthesiser.  But not if you constrain the representation it must use in the language spec.

(Note, I'm not making the case that there are tools which do this, or that I have a particular real-world use-case personally - just making sure we consider the implications of specifying something more tightly that it currently is!)


> > these operators for? Some examples which occur to me off the top of my
> > head:
> > • Masking bits
> 
> yes.
> 
> is an array index even ?
> 
> if (i and 1) = 0 then
> 
> then use a shift right to get rid of the LSB.
> 
> application : walking in a binary tree,
>    useful for certain compression systems
>    and countless other binary algos.
> 
> And implementation-wise, more "natural" and "fast"

Personally, I'm less bothered about implementation that code-readability.

> for the CPU than mod 2 and / 2 (many cycles when the synthesiser does not bother to optimise).
> 

I'll be staggered to find a synthesiser which can't optimise mod 2 and /2!

> > • Shift registers (should simulate faster than vectors, but whether 
> > this is significant I don't know!)
> 
> obviously it "should".
> LFSR are a natural application,
> which yields some very good pseudo-random number generators.
> 

Indeed so

> > • Xoring in crc generators
> 
> CRC is just a LFSR looked from the other side of the equation :-)
> 

Yes, I guess so :)

> > • What else?
> 
> Crypto. Not because I have interest in it but because if you can do it well, you can do the rest well.
> 
> Simple graphics : blitting, pixel handling...
> 
> Bit and byte packing.
>    Have you ever tried to pack 4 bytes into a 32-bits word in VHDL ?

A <= b & c & d & e

I guess you are suggesting the above should work with integers as well as with vectors?  Good point.

>    what about extraction ?
>    Mod and divides don't work well in practice.
> Application : ANY simulation/emulation system that needs to import/export
>     binary data streams, adjust format, change endianness...
> 
> Compression/decompression. Can someone implement the gzip codec in pure VHDL without losing its sanity ?
> 
> > Things it probably shouldn't be used for (in future) could be:
> > 
> > • Power-of-2 Wraparound counters - we'll have modular types for this
> > 
> > • Others?
> 
> "shouldn't be used" is not a good approach, because the intent of a feature rarely outlives the benefits of its implementation.

I'd take the view that using a modular type more correctly expresses the intent of the author.  An integer is supposed to fail if you assign outside of it's range. A modular type is not.

> Integers were meant for being "just loop counters and indexes for arrays"
> but the language and the EDA landscape has evolved way beyond that.
> Today VHDL does much more than merely describe circuits.
> 
> Modular types are interesting, but its (planned) support for logic/boolean comes from the lack of it in integers.
> Now if/when integers support logic/boolean, I can imagine that implementors will not want to implement (or delay) modulars because it's a lot of work while the integers provide the missing feature (with minimal effort). This might anger purists.

That might be me you're talking about then :)  See above.  Adding wrap-around to integers is something I won’t support.

> 
> > Is this a proposal worth further consideration or not? I see three 
> > options at this stage, but am of course open to others!
> > 
> > • Don't allow it, it's too constraining on the implementation - use a 
> > modular type if you want bit operations.
> 
> I could go for it.
> 
> > • Allow it, but only on integers which have a range covering a 'full 
> > power-of-2'
> 
> That's my favorite choice.
> In the last proposals, I don't remember limiting its use on **2.
> It would solve most practical problems I have encountered in my early experiments.
> 
> I'd say, constrain ranges to 0 to 2**n -1, or -2**(n-1) to 2**(n-1) -1 : this way, both signed and unsigned powers of two can work without issue.
> 

Agreed, I wasn't proposing +ve powers of two only, but I wasn't clear about that.

> > • Allow it on all integer ranges - in which case how to treat things 
> > like integers ranged 157 to 160 - should the compiler normalise that 
> > to 0 to 3 for logical and shifting purposes or treat them as 
> > effectively full-width 2s complement vectors
> 
> Keep It Simple, please :-)
> 
> #2 (with signed and unsigned ranges) sounds best to me.
> 
> > Thanks,
> 
> Thanks for bringing this back.
> 
> Now comes the question : if integer bool/logic becomes possible, what would modular types become ?
> modulo arithmetic is / can be emulated with existing constructs, but bool/logic can't. mod, * and / can do a few tricks but really not much. Try coding "A and 1101101" with mod, * and / ...
> 

Modular types are still useful for expressing a different design intent.

> Finally, bool/logic support is not meant to replace bit vectors, because integers have a limited range (32, eventually 64 bits).

Or more!  It could potentially replace bit vectors for (almost?) all arithmetic purposes...

> However, a future "Universal Integer" should support bool/logic anyway as well, because it would break the language's orthogonality.
> 

I'm not sure what you mean by this phrase, can you give some examples?

> I'll be back again in a few days.
> 

We'll still be here :)

My summary of all the above is that it would be "pleasant" to be able to perform these operations on integers.  But I don't see anything which can't be done with unsigned/signed vector (at the expense of simulation performance, but maybe the effort of implementing this could be better spent improving the simulation performance of vectors to more closely-match integers in these sorts of use-cases?)

Cheers,
Martin


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