Re: further discussion on implications of typing rules

Hi all,

many thanks to Bob for his summary. It very much resembles my issues as 
well, which makes my task much
easier to describe my confusion/concerns of the call last week.

There are only a few comments on top of Bob's summary:
 - I believe strong typing is good for defining on how to perform 
parameter conversions; the question here is
    how much automatism is desired/expected. As already discussed in the 
call there are a certain set of types
    that can not be converted easily without more user interaction.
 - Therefore an user should have the capability to define/override the 
conversion functionality
 - I fully understand the concern that this might need extensions to the 
other languages; it might be worth to
   check whether the corresponding functionality can be provided on the 
SV side only.
 - for me the translation part is the important topic -- not so much 
that we need such a thing and that strong
   typing is important for this functionality.

That's my $0.02.

Best regards,
-Michael


Bob Shur wrote:
>
> At last Wednesday's meeting I expressed confusion about the 
> strong/weak typing proposal. I think most of my unease comes from not 
> understanding the context of the discussion. Possibly the rest of this 
> message is based on a misunderstanding of what was being suggested. If 
> so, I apologize.
>
>  
>
> If there was a proposal on the table, I wasn't clear on what it was.
>
>  
>
> If the idea was to define strong/weak typing, I have no objection.
>
>  
>
> I heard the idea that we should be careful to define things such that 
> a if a language enforces strong typing then it should not be possible 
> to circumvent that by mixing languages. This seems reasonable. I don't 
> know when it applies, though. Some examples of where we're in danger 
> of having this problem would help me.
>
>  
>
> I'm also not clear on the definition of strong typing. For example, 
> when you call a C++ function, you have to pass actual arguments that 
> are convertible to the formal arguments. You can pass an A to a 
> function(B) as long there's there an A::operator B or B(A) 
> constructor. I'm not sure whether you're calling that strong typing or 
> not.
>
>  
>
> The example of an SC interface was given in  John Shields' message of 
> April 26, in which he said:
>
>  
>
> For example, SC certainly has strong requirements for matching class 
> types at its interface.  Defining, generating, and using equivalent 
> derived declarations to do type checking between SV or VHDL and SC 
> should be part of the specification and implementation.
>
>  
>
> I'm not sure what was meant by "equivalent derived declarations" here. 
> My view is that where SC needs an object that implements some 
> interface, the object has to be, in fact, a C++ object that implements 
> the interface. There's not much choice, since the C++ code that makes 
> calls to that interface is compiled by an off-the-shelf C++ compiler 
> and assumes that the object it's calling is  a C++ object that 
> implements the interface. This object may not be the same one that 
> user mentions---for example, if the user tries to bind a verilog class 
> instance to a SystemC port we might create a behind-the-scenes C++ 
> object that we bind to the SystemC port, with the behind-the-scenes 
> object somehow linked to the Verilog class instance. I see no apriori 
> reason why the Verilog object and the behind-the-scenes C++ object 
> have to be the "same" type---only that operations on one can be 
> translated to operations on the other.
>
>  
>
> I'm happy with the idea of coming up with a way to enforce, or create 
> by construction, "same" types in multiple languages. But I expect we 
> will also need to come up with a way to populate a library with 
> converters between types in different languages. In that case, the 
> "same" types would become a special case in which the converters were 
> automatable so the user would not have to think about them.
>
>  
>
> If what I've attempted to express here does not conflict with what I 
> was asked to vote on last Wednesday, then I'm happy to change my vote 
> from "need more time" to "yes".
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 


-- 


NOTE:
The content of this message may contain personal statements which are not 
neccessarily the view of Freescale, unless specifically stated.

         ___________________________________________________     
        |                                                   |
        | Michael Rohleder            Tel: +49-89-92103-259 |
     / )| Principal Staff Engineer    Fax: +49-89-92103-101 |( \
    / / | Freescale Semiconductor,        www.freescale.com | \ \
  _( (_ |  _        New Product Development Center       _  | _) )_
 (((\ \>|_/ >  Schatzbogen 7, D-81829 Muenchen, Germany < \_|</ /)))
 (\\\\ \_/ /    mailto:michael.rohleder@freescale.com    \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

This e-mail, and any associated attachments have been classified as:
[ ] Public
[ ] Freescale Semiconductor Internal Use Only
[x] Freescale Semiconductor Confidential Proprietary


    Freescale Halbleiter Deutschland GmbH
    Schatzbogen 7
    D-81829 Muenchen
    www.freescale.com

    Sitz der Gesellschaft/Registered Office: Muenchen
    Registergericht/Registered Court: Amtsgericht Muenchen HR B 151590
    Geschaeftsfuehrer/General Manager: Juergen Weyer, Karen Roscher, 
                           John Pence, Oliver Kaltenbach, Andreas Wild
    USt.-ID-Nr./VAT-ID-No. DE813898243
    Steuernummer/Tax No. 143/138/30552


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