Subject: Re: [sv-cc] Comments on Michael's documents
From: Francoise Martinolle (fm@cadence.com)
Date: Mon Mar 03 2003 - 12:18:43 PST
At 11:52 AM 3/3/2003 -0800, Kevin Cameron wrote:
>
>
>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.
When 1364 was standardized, all switch names and existence were removed
from the
standard. The reason was that command line options were completely different in
VCS, NC and VXL. A switch is the implementation of a mechanism. There are many
possible switch implementations for a mechanism, one can have one swich
followed by a sequence of values, one can have a different switch for each
value, etc... The standard should not privilege a particular implementation.
That is to say that when systemVerilog gets folded in Verilog 1364, the
mention of switch will be removed.
>>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>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 - 12:22:44 PST