Subject: Re: [sv-cc] Updated proposal for C/C++ file inclusion
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Jan 28 2003 - 07:52:00 PST
John,
thanks. This is a lot of very good input. I like this, it will help to make the proposal even better ...
-Michael
"Amouroux, John" wrote:
> Michael,
>
> You do good stuff. Don't be surprised if Swapnajit tries to enlist you for
> the LRM work! ;^)
Hmmm. Honor or threat, this is the question ? (see Shakespear)
> I have a few questions and comments about the object code section.
>
> 1. default sv_root required?
> I'm not sure I agree that all the libs with relative paths should be
> location-independent. I would prefer if the default sv_root was the current
> working directory. But then again, I'm not responsible for administering a
> large group of CAD tool users.
Actually, you bring up a good point here. I think it is shortcoming that there is no default defined for sv_root. So what would be
the actual pathname for a relative pathname in absence of an environment variable SV_ROOT and before a -sv_root specification ???
And yes, it might be a good idea to define the current working directory for those cases (although I personally hate such kind of
definitions, but it makes sense in this cases).
> 2. Required #!SV_LIBRARIES directive in the bootstrap file
> Typically these types of "#!" comments are used to direct processing of
> files to a specific interpreter executable. But in this case there is no
> such executable, so I don't understand the need. Can you explain your
> reasoning for this?
We are using these kind of identifiers to clearly identify the file type. This is very useful to early detect user errors
(specifying the wrong file) and might also be useful as tag for tools like 'file' (similarly to the markers %PDF for PDF files and
%!PS for PostScript files - Adobe knew why it had inserted them). It is much easier to properly abort an errorneous specification
with a proper error message (wrong file type!) than when relying on some parser errors ... Just think about an user mixing the
object code bootstrap file with the source code bootstrap file. This is a likely problem to occur.
> 3. setenv SV_LIBRARIES syntax
> Since simulators must run on Windows machines, we cannot rely solely on a
> colon as a path separator because Windows uses this for its drive specifiers
> (i.e c:\windows). A space character is also problematic because Windows
> also allows spaces in names. I've seen GNU make solve this problem with the
> following approach. They accept colons and spaces as the default separator
> *unless* the first character of the variable is a colon or semi-colon. In
> this latter case they then take that first character as the separator. We
> can probably do the same thing, but simplify things by never allowing space
> as a separator.
Hmmm. You are fully right. My fault. The only excuse I have is that I am sometimes selectively blind for the issues of this ...
(sorry, can't say operating system here, this would be too much honor). And yes, the GNU solution is the best for this issue
(including your extension to forbid blanks). Thanks!
> For example, given the libraries "lib/abc", "/root/my lib/def", and
> "/home/boy/lib/ghk" the following are all equivalent:
>
> Unix/Linux: (note the space in "my lib" must be escaped on Unix)
> setenv SV_LIBRARIES "lib/abc:/root/my\ lib/def:/home/boy/lib/ghk"
> setenv SV_LIBRARIES ":lib/abc:/root/my\ lib/def:/home/boy/lib/ghk"
>
> Windows: (note there not a setenv that comes with Windows - this is done
> differently - I've just simplified the example)
> setenv SV_LIBRARIES ";lib\abc;C:\root\my lib\def;C:\home\boy\lib\ghk"
>
> 4. small example bug?
> In example 2 in the left column you've included the file extensions (.so,
> .a). Aren't these supposed to be omitted?
Yes, my fault. :-(
I wrote it on Sunday ...
> Regards,
> John A.
>
> > -----Original Message-----
> > From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
> > Sent: Monday, January 27, 2003 1:24 PM
> > To: SystemVerilog CC DWG
> > Subject: [sv-cc] Updated proposal for C/C++ file inclusion
> >
> > Hi all,
> >
> > please find below the updated proposal for the inclusion of C/C++ code. As
> > requested in the last meeting, I have split it into two
> > parts: Object Code inclusion and Source Code inclusion. The result
> > consists now of three parts:
> > . a common introduction
> > . the part about Object Code inclusion
> > . the part about Source Code inclusion
> > [the rationale behind this organization is that the addition of a PLI/VPI
> > inclusion mechanism as requested in the meeting could be
> > easily accomplished as third part, with only minor changes to the
> > introduction]
> > I have further added a complete set of switch settings for all environment
> > variables (as requested by Joao) and further provided a
> > mechanism to disable the usage of environment variables. Change bars are
> > used to show all modifications. Since I have done some
> > restructuring in the switch/variable parts of the source code part, there
> > are a lot of changes in this part ...
> >
> > Have fun reviewing!
> >
> > Best regards,
> > Michael
> >
> > --
> >
> > 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! ***
--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 : Tue Jan 28 2003 - 07:53:38 PST