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

Le 2014-08-29 12:20, Martin.J Thompson a écrit :
> Hi all,

Hi,
sorry for being late, the wifi in the middle of the countryside
in Holland is not as handy as DSL at home :-)

> There was some discussion on yesterday's telecon of allowing logical
> operations on integers. There is also quite a lot of previous
> discussion here:
> 
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/IntegerOperators [1]
> Shift operators could also be considered.

http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ModularTypes
contains other interesting considerations.

> 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 ?

> So in terms of gathering requirements, what would people like to use
> 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"
for the CPU than mod 2 and / 2 (many cycles when the
synthesiser does not bother to optimise).

> · 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.

> · Xoring in crc generators

CRC is just a LFSR looked from the other side of the equation :-)

> · 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 ?
   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.
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.

> 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.

> · 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 / ...

Finally, bool/logic support is not meant to replace bit vectors,
because integers have a limited range (32, eventually 64 bits).
However, a future "Universal Integer" should support bool/logic
anyway as well, because it would break the language's orthogonality.

I'll be back again in a few days.

> Martin
YG

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