Re: [sv-bc] Type of a concat expression

Hi Shalom.

On 06/18/2010 04:01 AM, Bresticker, Shalom wrote:
> It's very useful, as in the following where the types of a and b are parameterized:
>
> var type({a,b}) c = {a,b} ;
>
>
> Note also the following. Consider the expression
>
> expr1& expr2
>
> As part of our coding guidelines and code checks, we require that the self-determined types of expr1 and expr2 be the same. Otherwise, it is with high probability a coding mistake. This is despite the fact that when the expression is evaluated, the shorter of expr1 and expr2 will be size-extended to the size of the longer.
>

I don't understand this. If a is signed and b is unsigned, a & b is
perfectly fine coding: The bit patterns are the
same for signed and unsigned vectors, and masking a signed object
with an unsigned mask (for example to normalize the sign bit)
seems to make good sense.

Verilog automatically handles this kind of "coding error".

The problem with "strong" (viz., intolerant) typing is that it
wastes effort in complying with unnecessary rules -- at least
in verilog as opposed to some other languages.

It is not consistent with good language design to mix guidelines for
"strong" and "unstrong" typing. It creates inconsistency
and makes for a shallower learning curve for beginners.

This was the main reason that C became so popular when
compared with, say, Pascal or PL. C was designed to help the
programmer to get his or her work done; Pascal was designed to teach
students about type differences and to make compiler
development simpler.

After the ANSI Std, one could write C in "strong" types simply by
declaring all variables in tagged structs. No further language
constructs or compiler rewrites were required, just application
of an existing language construct for the additional functionality.

A high probability of a departure from coding guidelines is not
the same as a high probability that the compiler will report
an error, or that the code will behave badly. One has to
take take account of what it is that the coding guidelines have been
based upon -- Just take a Bayesian view in that the prior condition
is an important factor in the probability under discussion.

Excluding the C++-compatibility side of SystemVerilog, verilog is
not strongly typed; so, imposing "strong" type assumptions on
coding guidelines merely creates complexity, and complexity
consumes development time and encourages error.

> Shalom
>
>
>> In verilog, and in the scheduled design constructs of SystemVerilog,
>> the "type" of an expression is useless, because
>> the way an expression is used determines the meaning of
>> the expression. It is possible, but very rare, for
>> a verilog expression to have a self-determined "type".
>> Signed vs. unsigned relational expressions come to mind.
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.