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

"rickman" <gnuarm@[EMAIL PROTECTED]
> wrote in message 
news:bdf4e73d-f1d1-460d-a92c-be0518f01f56@[EMAIL PROTECTED]
>> > 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?

In C/C++, "promotion" of signed integer values is sign-bit extension; 
unsigned promotion is zero-extension. It seems a resaonable enough
approach 
to the problem you define. You only need to clearly establish whether your

literal constant is signed or unsigned.

>> > Maybe my software courses
>> > in college were too long ago for me to have learned why strong typing
>> > has to be so ***bersome.

C++ clearly defines type coercions, but we needn't go there on this, I 
think. I can tell you that allowing C-style typecasts, similar to VHDL 
typecasts, defeats its type system. VHDL, by not allowing more reasonable 
constructs, encourages the same abuse and misuse.

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

Yikes. Are there times when the two would be defined differently?

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

I can see some issues. But so far, it sounds like you only want to better 
define assignment of signed/unsigned integer values and literal constants.

Size promotion rules will cover it without fighting that battle.

What other use would you have for assignment overload?