Re: Signed, Unsigned syntax issues. Please help, I'm stumped

On Jun 13, 10:35 pm, "KJ" <kkjenni...@[EMAIL PROTECTED]
> wrote:
> "rickman" <gnu...@[EMAIL PROTECTED]
> wrote in message
>
>
news:37c87ac4-768f-405f-a262-fe3e4dd0c51b@[EMAIL PROTECTED]
>
> > You present a nice list.  Thanks.
>
> >> 'A' has the advantage of clarity of intent...it has the drawback of
> >> requring loose type checking in the language.
>
> > This is the issue that I am struggling with understanding.  Strong
> > type checking is good in many contexts.  But I fail to understand why
> > it has to prevent me in this case.  In fact, I think that someone said
> > that this is being proposed for the next, next rev of the language.
> > So obviously it does not present any real issues to make it
> > incompatible with strong type checking.
>
> It breaks the rules of strong type checking because 'CTPBitCnt' is of
type
> 'unsigned' and '1' is of type integer and assigning something of one
type to
> something that is of another type directly without some form of
conversion
> function breaks what is considered to be strong type checking.
>
> Relaxation of the rules in certain instances (like this one) can be a
> productivity enhancer and a 'good' thing for the language but you should
> also accept that this relaxing of the rules IS a violation of strong
type
> checking.

I think my point is that calling 1 an integer is arbitrary.  It has
been defined as an integer, just like X"5A69" was originally defined
as a bit vector.  But we can also see it as a std_logic_vector and
understand its meaning.  I feel that calling 1 an integer is
arbitrary.  I can consider it to be a unconstrained slv literal just
as easily as an integer.  I understand that this is not part of the
language, but I don't see any reason that it can't be.  I don't see
any ambiguity in considering integer numbers to represent slv of
indeterminate length.


> >> 'B' has the advantage of clarity of intent...and it meets the
> >> requirements of strong type checking and is not overly wordy.
>
> > I honestly don't understand why the intent is not clear in example A.
>
> Flip back and you'll see that I said that both 'A' and 'B' are clear
about
> the designer's intent.
>
> > I specified that CTPBitCnt was an unsigned signal in the declaration.
> > Does it make any sense to assume that I mean the literal 1 to be
> > anything other than an unsigned equivalent?
>
> I hate having to flip back to the declaration to see what the type of a
> particular signal is.

Then how would you know to write unsigned(... rather than
signed(... ?  Once the code is written, the meaning is obvious, assign
the numerical value 1 to the signal in whatever format is
appropriate.  Do you need to know that the signal is signed or
unsigned to understand this assignment?

> > Maybe my software courses
> > in college were too long ago for me to have learned why strong typing
> > has to be so ***bersome.
>
> It needn't be...overrides for "<=" and ":=" would solve the wordiness
> problem and still provide for the strong type checking....as someone
else
> stated, other languages have it.  The needed conversion function can be
the
> function that provides an operator overload....just like how one can
> overload "and", "or", etc. to work with custom types today.

Yes, I think we all agree that would be a good idea.  I just don't
understand why it has taken the experts over 20 years to figure this
out.  I have only worked with this stuff part of the time and even
then I was just trying to get something done with it, not invent the
language... and I can clearly see the need.


> >> 'D' is kludgy but fairly succint in getting the intent across.
>
> > I assume this is a special procedure to perform the required function
> > by reading the middle term?  Interesting...
>
> Yes, it would be a homegrown procedure that one would put into a package
of
> commonly used functions.  Just as you get into the habit of including
the
> std_logic stuff at the begining of every VHDL file you would start to
> include your package of homegrown stuff and then always have these
shortcuts
> handy.
>
> By the way, the middle term "<=" wouldn't even be used by the procedure
it
> would simply be there to aid the reader since something like this
>
> set (this, that)
>
> would always cause someone to say, well does that mean
> this <= that
> or
> that <= this?
>
> whereas
> set (this "<=" that);
> would be more clear...at the expense of more typing....for a parameter
that
> doesn't functionally contribute anything...I can hear the moans and
groans
> already, but you can make your homegrowns your way, I'll make 'em mine.

Personally, I think set (this, that) is just fine.  It is a strange
construct to begin with.  But once someone learns about it, it is very
easy to remember that the order is the same as in an assignment.  No
confusion there.  Or you could name it set_to(this, that) as in "set
this to that".  This is starting to sound a bit like Forth...!


> The procedure should have an assert to make sure that the middle term is
> "<=" though so that some smarty pants that said
>
> set (this, "=>" that)
>
> would get hammered in simulation by firing an assertion.
>
>
>
> >> 'E' is valid VHDL'2008 that has lost the designer's intent...15D??
> >> hmmm....
>
> > To be honest, I don't see how this one can even work.  Is this
> > intended to indicate a signed or an unsigned value?  How do you
> > indicate the other?  I don't need to say anything about the 15 part...
>
> VHDL has a lot of nice things....this one isn't one of them...well,
assuming
> that it actually gets approved.
>
>
>
> > The more I read about this, the more I like Verilog... at least until
> > I start using it ;^)
>
> comp.lang.verilog is always looking for members....and from what I read
> Verilog is finally catching up to VHDL.
>
> KJ

Well, I still need to get this one done.  I'll wait and see if I am
still inclined to jump ****p when I start the next project.

Rick