Re: [sv-cc] Comments on Michael's documents

Subject: Re: [sv-cc] Comments on Michael's documents
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Sun Mar 02 2003 - 13:11:51 PST

Francoise,

thanks a lot for this feedback. Please see below my responses ...

Best regards,
-Michael

Francoise Martinolle wrote:

> Michael,
> my comments are embedded in your latest document (pink color).
>
> in summary:
> - no switch names or switch existence should be specified in the standard

Sorry, but this goes too far.

I clearly said in the last conf call, that the important part is the switch semantic. Without specifying the existance of a switch
there would be no semantic at all. What are we then standardizing on? On the need to have a common inclusion methodology ?

I can agree to not make the switch _name_ part of the standard, but what you demand is far, far more.

And the intention of specifying switch names is a) to make the text readable and b) to still to have some uniformity (because most
vendors will adhere to those proposals). If someone wants to use a different switch name, fine.

> - no priority should be defined between bootstrap files and straight shared library files names

Why?

> - In the part1 document you write:
> "The SystemVerilog application should only load object code within a shared library that is referenced by the SystemVerilog code
> or by registration functions; loading of additional functions included within a shared library should be avoided, because they
> might interfere with other parts."
>
> while using dlopen to dynamically load a shared library, dlopen will load any other
> libraries on which your shared library depends on. There is a mode where you
> can pass to dlopen to delay external symbol resolution when they are used.
> but I don't think this should be specified by the standard.

IMHO this is just some misinterpretation, I would like to ask you to help me to solve:
a) it is stated "... load object code _within_ a shared library ...", this does not refer to any _other_ libraries
b) the main purpose for this statement is to avoid interferences when this is possible
c) this is rather neat feature for users that want to use only a partial subset of the "extern" functions provided within a library
without having to rebuild the library every time a different subset is being used
d) this is a "should" statement that is worded rather soft; I am not religious at all about it.

> - you also write that a share library should only be loaded once.
> How is this going to checked? Why such a requirement?

I thought we have discussed that in the last conference call already.
The reason for this is that you _might_ experience warnings/errors when loading a library multiple times. We said that it should
only be loaded once, when it is possible to identify duplicates e.g. by checking for inodes ... 

--

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

         ___________________________________________________
        |                                                   |
      _ | Michael Rohleder            Tel: +49-89-92103-259 | _
     / )| Software Technologist       Fax: +49-89-92103-680 |( \
    / / | Motorola, Semiconductor Products, System Design   | \ \
  _( (_ |  _   Schatzbogen 7, D-81829 Munich, Germany    _  | _) )_
 (((\ \>|_/ >                                           < \_|</ /)))
 (\\\\ \_/ /    mailto:Michael.Rohleder@motorola.com     \ \_/ ////)
  \       /_______________________________________________\       /
   \    _/                                                 \_    /
   /   /                                                     \   \

The information contained in this email has been classified as:
Motorola General Business Information (x)
Motorola Internal Use Only            ( )
Motorola Confidential Proprietary     ( )

*** This note may contain Motorola Confidential Proprietary or
    Motorola Internal Use Only Information and is intended to be
    reviewed by only the individual or organization named above.
    If you are not the intended recipient or an authorized representative
    of the intended recipient, you are hereby notified that any review,
    dissemination or copying of this email and its attachments, if any,
    or the information contained herein is prohibited. If you have received
    this email in error, please immediately notify the sender by
    return email and delete this email from your system.
    Thank you! ***

This archive was generated by hypermail 2b28 : Sun Mar 02 2003 - 15:27:56 PST