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

Dave, 
I think that you've made a mistake you've register a mantis: 
0002473: bit-stream cast to destination class must be constructed or made
illegal 
this is made illegal in draft 6 just as I've pointed out:
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) 
Which you've commented  but you probably haven't notice that sentence said
not only about arrays but also about classes:
[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.

Anyway for me that's ok if LRM forbids casting to class type but IMHO the
best place for the text would be in chapter : 6.24.1 together with the 1st
description. I was surprised - because I thought about static cast in more
C++ way. It leaves the control to the user and produce fatal exception on
runtime - in contrast to $cast which only do not perform the assignment if
types are not compatible. For me this would be the best solution - and maybe
it is not too late to define it for class to class casting. Casting to class
from type different that class may still be disallowed.

Using the same syntax for different features usually makes problems and it
is not worth to spare some BNF entries ;)

DANiel

 

  _____  

From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
Sent: 10 września 2008 16:06
To: Daniel Mlynek; sv-ec@server.eda-stds.org
Subject: 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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

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