RE: [vhdl-200x] More operators for integers

Le 2014-10-22 09:53, Martin.J Thompson a écrit :
> Hi YG,

Hello !

> Actually, I don't think we differ much, it's just that I haven't
> explained my thoughts well enough :) (Although I'm not sure we can
> have a type called integer and claim it just to be a bag-of-bits
> ever!)

why not ? ;-) in the end, it's just bits
and we decide what they represent or mean...

> My intention was that it *is* the assignment which would result in an
> error. Not the actual operation.  I shall clarify that.

OK.

> Also, I had intended to note that the LRM should make sure that the
> range of an integer is the full 32 bits (so "not integer'high" can
> still be assigned to an integer.
> Maybe we should also require that natural is a full +ve range 32-bit
> int rather than a subrange...

Well, this is a different topic, and the definition is so old that
it would be hard to change it...

> Can you post some of your (intended) use-case code? And then I'll add
> it to the Twiki as a 'real-world' requirement, which would be very
> useful.

I have a bit of actual code where I tested different approaches and
compared my "boolean extensions" with standard bit_vectors and 
std_ulogic_vector
http://ygdes.com/GHDL/int_bool/
In this case, I coded SHA-1 because it relies mostly on integer 
operations,
as seen in http://ygdes.com/GHDL/int_bool/sha-1.vhdl

But my concerns are more about data stream processing, like compression,
because this would greatly enhance the environment around simulations.
So this is not about replacing std_logic_vector or (un)signed,
it's about bringing modern interfaces to the toolset of the designer.
Imagine, you could compress or decompress test vectors with LZW or LZMA
directly in your simulator... I have an almost-working LZW codec
in C, I'm sure it would be useful to a lot of people if it was ported
to VHDL.

Even a simple byte shuffling procedure like this would more than benefit
from booleans :

   procedure save_pixels(n: string) is
     type screen_line is array(0 to (3*fbx)-1) of character;
     variable buff : screen_line;
     type screen_file is file of screen_line;
     file pixout : screen_file open write_mode is n;
     variable i,j,k,l: integer;
   begin
     for j in 0 to fby1 loop
       l:=0;
       for i in 0 to fbx1 loop
         k:=pixel(j,i);
         buff(l  ):= character'val((k/65536) mod 256);
         buff(l+1):= character'val((k/256)   mod 256);
         buff(l+2):= character'val( k        mod 256);
         l:=l+3;
       end loop;
       write(pixout,buff);
     end loop;
   end save_pixels;


(screenshot code from http://ygdes.com/GHDL/fb/fb_ghdl.vhdl I skipped 
the BMP header)
A very similar and usual code is byte swapping (endian adjustment),
used very often for networks.

Division is known to be slow. But the modulo was not optimised by the 
compiler,
even worse, it used floating point routines, so saving a whole screen 
would
take minutes...

Yes, the compiler should have optimised it, but that's not the point :
in the beginning, it's not a modulo that I wanted to do, but a mask,
and a mask is done by AND. Using an arithmetic operation to perform
a boolean operation is a kludge... I wrote arithmetic operations
and the compiler performed arithmetic operations.


Concerning boolean on ints for simulation, the modular type
is preferred. In practice, we want to deal with bit strings of
arbitrary lengths but the bool/shift operations force the code
to contain tons of masks. The source becomes heavy and brittle,
I didn't go far. This is why the SHA-1 example is a stereotypical
"microbenchmark" because it natively works with 32 bits integers,
it does not have to deal with other sizes and it demonstrates
maximum speedup. However when I try to code an actual circuit,
the source code size doubles and I have to keep all the mask sizes
coherent... The modular solves this because each variable would
have a modulo attribute, post-adjustments are performed behind
the scene instead of writing redundant code everywhere...

I hope this little feedback helps you,

> Cheers,
> Martin
YG

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