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

"rickman" <gnuarm@[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.

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

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

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

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