Arbitrary range integers (was RE: EXTERNAL: Re: [vhdl-200x] Modular types)

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of ryan.w.hinton@L-3com.com
Sent: 01 July 2014 18:22
To: vhdl-200x@eda.org
Subject: RE: EXTERNAL: Re: [vhdl-200x] Modular types

> It should be a little longer than that.
> (2**31) ** (2**31)
> is over 20 billion digits base 10.  (Notice the larger exponent.)  Python has been working on this for 10 minutes now -- and it's up to about 100GB of memory.

Indeed.  I've looked back and I'd done 2**31**2 - I'm now not sure why I wrote 10**31**31! 

The point I was intending to make was that for "reasonable" sized numbers it's fast enough, and for larger numbers, well, it's just a matter of time (either processing time, or waiting for new hardware to come along :)

> The idea of arbitrary-precision integers is not necessarily to describe a particular piece of hardware.  It's to
> provide a programming language with infrastructure that makes it convenient to describe arbitrary hardware.  I 
> regularly use ~100-bit intermediate accumulators (CIC filter), and 500- to 4000-bit pseudo-random number
> generators, and 2000 to 64k bit LDPC error correcting codes.  And I haven't yet been asked to work on a crypto 
> problem!  So why should my programming language be limited by the "32 bits is big enough for anyone" idea?  

Quite.

> I'm not expecting arbitrary-range integers to be synthesizable any more than FILE or ACCESS types.  (Although a 
> friend had some interesting ideas on synthesizable pointers....)  I use numeric_std types for synthesis, or 
> sometimes a range-restricted integer.  But it would be great for the simulator to support it.

I agree - not completely arbitrary range (for synthesis), but an arbitrary range-restricted integer should be available (limited only by available hardware constraints as usual!)

Cheers,
Martin

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