Subject: Re: $root, prototypes etc.
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Mon Mar 18 2002 - 14:53:53 PST
Peter Flake wrote:
> Kevin,
>
> In spite of its supposed deficiency in the global namespace, C has been
> more successful in the marketplace than languages which avoid this problem,
> such as Ada or Modula-2, or even Java.
Yes, and I think we should take as many of it's good features as possible :-)
[and avoid repeating its mistakes]
> The reason for having prototypes in C is that compilation of each file is
> separate, and the linker does not check the number and types of
> arguments. In SystemVerilog, as in Verilog, the whole source is used for
> compilation so the number and types of arguments can be checked by the
> elaborator. Furthermore this avoids the need to use name mangling as the
> means of applying overloading to a linker with a single namespace, if we
> wanted to add overloading to SystemVerilog.
>
> It is so incredibly tedious to write
> extern void printf(char *, ...);
> extern FILE *fopen(char *, ...);
> etc.
> that people write
> #include <stdio.h>
> instead.
>
> Do we want to force users to create headers of all the global names they
> will be using, and include them in every module? I don't.
Apart from easing incremental compile, 'extern' definitions help define
a block of code as self-complete. If you need to do something like
communication synthesis you can treat blocks hanging off the busses as
black boxes - just declare them 'extern', and you can hang attributes
to drive synthesis on that declaration.
Not all tools need to see all the code, but it is essential that all tools
have a consistent view, 'extern' declarations help do that. A SystemVerilog
definition of a module should have the same interface as its equivalent
Verilog-200* synthesized view or Verilog-A view - that's why VHDL
split modules into "entity & architecture".
From a methodology standpoint anything that helps integration engineers
avoid stupid mistakes is a plus, if the price is a few more keystrokes
for the design engineers I think it is a reasonable trade-off.
Regards,
Kev.
> Regards,
>
> Peter.
>
> At 10:06 AM 3/15/02 -0800, Kevin Cameron x3251 wrote:
> >[Previous post - http://www.eda.org/vlog-pp/hm/0125.html
> > - includes proposals]
> >
> >C programming uses a global namespace similar to $root for
> >all routines. Originally it didn't use prototypes, you just
> >found routines by their name at link time. That's fine as
> >long as there isn't a lot of code, once you do have a lot
> >of code you need to add checks to make sure that you are
> >calling the right routine e.g. always include the routine
> >prototype so that you get the declaring module checked
> >against it and the the module using it has the same
> >interface. C++ uses "name mangling" which transforms the
> >simple name of the routine into one dependent on its
> >parameter types so that their is no confusion about what
> >code to call (and you can overload the routine).
> >
> >The addition of new data types and the $root namespace
> >in SystemVerilog will lead to the same problems as seen
> >in C programming. So in an effort to be preemptive I
> >think we should add all the prototyping mechanisms now
> >rather than later, and disallow "lazy" linkage from
> >the start. This will also help with modular compilation
> >and hence compiled IP/library reuse, and interfacing
> >to foreign languages.
> >
> >Proposal:
> >
> >1. All items used from $root should be declared fully by
> > prototype, or by forward reference before use, unless
> > backward compatibility dictates otherwise.
> >
> >2. Add syntax:
> >
> > Tasks and functions without statements are considered
> > prototypes.
> >
> > 'extern' before 'module' and 'interface' indicate a
> > prototype and limit the contents to structural items
> > and public methods - which should match the actual
> > declaration if seen.
> >
> > Ellipsis "..." can be used when there is an unknown
> > number of a arguments.
> >
> > 'extern' before an (unsized) variable declaration
> > behaves as in "C".
> >
> >
> >While we are not doing function/module overloading at
> >the moment it may be necessary to do it in future
> >(particularly for AMS) to make automatic configuration
> >during elaboration possible - i.e. I'm not suggesting
> >this stuff because I like excessive typing [ pun
> >intended :-) ], it'll just make some other things
> >easier later.
> >
> >Regards,
> >Kev.
> >
> >
> >--
> >National Semiconductor
> >2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Mon Mar 18 2002 - 10:58:04 PST