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

Hi YG,

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!)

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

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

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.

Cheers,
Martin


-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of whygee@f-cpu.org
Sent: 21 October 2014 18:21
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] More operators for integers

Le 2014-10-21 10:39, Martin.J Thompson a écrit :
> I'm merely wanting to be clear that errors will be raised in the usual 
> way and that there is no magic or changes to expected behaviour.  Not 
> necessarily that they will get much use, or that every operator *can* 
> result in errors, merely that there should be no surprises where 
> errors are concerned.
> 
> A "logical operator" example, if you have a +ve integer and "not" it 
> (ie flip every bit, resulting in a -ve number) and assign it to a 
> natural, or some other subtype without the appropriate negative range, 
> you will get an error.

I see where we diverge,
you consider the variables as numbers, as classic VHDL types.
However, the boolean operators consider our variables/data as a "ordered collection of bits" (at most). One of my usual examples is bitstream insertion/extraction: you need masks, shifts and and/or operators. The intermediary data are not real numbers, just bits waiting to be shuffled around to make sense for the other parts of the program. If you raise an error that would apply only on arithmetic numbers, you break the encoder or decoder.

Let's say I compute a mask and I need to make the complementary mask (for a MUX-like, or "select" operation).
At one point, my initial mask is 0000...., which excludes all the bits from one input. When I complement it, I don't expect at all to get an error. If it was the case, I would have to rewrite the whole algorithm to avoid the 0 case, which would make it uselessly complex (and probably slower).

You also raise the issue of the assignments to non-signed numbers.

(BTW here we touch an issue about VHDL : unsigned numbers are a sub-range of the signed numbers, we lose one MSB...)

The actual error handling should be in the assignment, not the operation itself. This implies that bool/shift/rot operations would work only on signed integers. I can live with that (and all the implied casts) as long as the whole range of boolean operators is available (for example, both srl and sra, so *I* can decide how to treat the bits).


I hope that it's clearer why I want to avoid throwing errors.
Restricting boolean use to a certain "safe" type avoids having to deal with them, I think. What's your opinion ?

> Cheers,
Thanks for your patience,

> Martin
YG

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