Subject: Re: [sv-cc] Comments on Michael's documents
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Mon Mar 03 2003 - 11:52:53 PST
Michael Rohleder wrote:
> 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).
>
Could folks stick to PDF please?
>> 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 ?
Switches depend on having a command line, you can't mandate a GUI driven tool has them.
> 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?
If you are doing dynamic loading you are likely to run into order dependence. The bootstrap files should
be able to support that - you need to add dependency rules. The bootstrap files should also support the
use of (environment) variables so that they are portable. E.g. $SV_SYSLIB could be set by the SV compiler
for vendor libraries. Being able to source other files would also be useful. I would suggest using a subset
of [g]make syntax for the bootstrap files so that the extra functionality is supported and the definitions are
re-usable.
I don't see why "#!SV_LIBRARIES" is required - 'SV_LIBRARIES' is not an interpreter, and the context
is not ambiguous.
Regards,
Kev.
>> - 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! ***
>
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Mon Mar 03 2003 - 11:52:54 PST