RE: [sv-ec] 6.24.1 static cast after mantis 1384 fix

 

 

________________________________

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Daniel Mlynek
Sent: Wednesday, September 10, 2008 4:55 AM
To: sv-ec@server.eda-stds.org
Subject: [sv-ec] 6.24.1 static cast after mantis 1384 fix

 

There is bunch of inconsitency and unclerance after mantis  1384 fix

LRM draft 6 :

6.24.1 Description of    static cast: "If the expression is assignment
compatible with the casting type, then the cast shall return the value
that a variable of the casting type would hold after being assigned the
expression. If the expression is not assignment compatible with the
casting type, then if the casting type is an enumerated type, the
behavior shall be as described as in 6.19.4, and if the casting type is
a bit-stream type, the behavior shall be as described in 6.24.3."

The sentence is still open - what should happened if dest and source is
not assignment compatybile and casting type is not an enum not
bit-stream type - is it possible? What about classes - are they bit
stream - is not so obvious

[DR] Assignments are illegal without assignment compatibility (6.22.3).
Some classes are bit-stream types if certain conditions are met
(6.24.3). Anything else is not defined and therefore not legal.

6.24.3: "An associative array type or class shall be illegal as a
destination type." (this was allowed in 1800-2005 now draft 6 bans it) 

Both above are contradictory - becaue 1st allows to cast to a type which
is assignment compatybile (which is possible for class handles - ie cast
to super class) while 2nd forbids static cast to  class type. IMHO there
are two solutions :

[DR] They are not contradictory. It is singling out a special case that
needs to be made illegal since there is no semantic definition for
creating the index to the associative array element.

    - cast to class should be fdisallowed in all cases - sentence from
6.24.3 should be moved to 6.24.1

    - cast between class handles should be allowed - it should not
perform any kind of check on compile/elab time - but on run time it
should triggger fatal errors if casted types are not compatybile - this
should be described in 6.24.3. [DR] This is what $cast does. Cast where
source is a non-class bit stream class and dectination is a class handle
should be forbidden in 6.24.3[DR]  The purpose of defining classes as
bit-stream types was specifically to allow packing/unpacking of class
members with non-class bitstream types. I personally was against this as
most classes will be disqualified by containing local or protected
properties, as well as containing properties that the user would not
want to include in their pack/unpack streams. I thought there was some
restriction about the class as a destination type saying the class must
be constructed before moving the bits. We defined this for the streaming
operators, but not for bit-stream casts. Mantis 2473 added

as an addition an example - what should be the behaviour of tool in
below example

class B;
    reg x;
    function f(); 
        $display("B",x);
    endfunction
endclass

 

class A extends B;

    int y;

    function f(); 
        $display("B",y);
    endfunctionendclass

 

module top;

    A a;[DR]  = new();

    B b;[DR]  = new();

 [DR] A and B are both legal bit-stream class types. B has 1 bit, and A
has 33 bits. 

    initial begin

        b = 'B(a);        /// should it be legal?? this is ok according
to 6.24.1 but offends 6.24.3[DR]  Illegal because the number of bits
don't match

        a = 'A(b);        /// should it be legal?? this offends both :
6.24.1 and 6.24.3[DR]  Illegal because the number of bits don't match

         'B(a).f();        /// should it be legal?? this show the only
sensible usage of casting to base class type but is this ok according
to syntax???[DR]  not legal for a number of reasons. Syntax does not
allow expressions in selects and cast to a destination class needs to be
constructed.

    end

endmodule

DANiel


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.