What is 'nsv' ?
Nick Ing-Simmons
Tk804.025_beta6 under blead was failing because it had
...
sv *nsv = newSVpv(...);
he = hv_fetch_ent(encodings,nsv,0,0);
if (!he || !HeVAL(he)) {
...
he = hv_store_ent(encodings,nsv,newSVsv(sv),0);
}
SvREFCNT_dec(nsv);
If I rename it nmsv it works.
Enache Adrian
>
> Tk804.025_beta6 under blead was failing because it had
...
...
> If I rename it nmsv it works.
Some macros using the gcc 'blocks in parens' extension
are quite naive.
Example:
#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && !defined(PERL_GCC_PEDANTIC)
# define SvREFCNT_dec(sv) \
({ \
SV *nsv = (SV*)(sv); \
...
They should use uglier names for their local variables (ex. __nsv,
or even better __SvREFCNT_dec_nsv :-)).
Regards,
Adi
Nicholas Clark
Or best of all be rewritten as inline functions, and then made available
to all compilers that support inline functions.
[Configure patch needed for that last bit]
Now, tell me where I'm going wrong...
Nicholas Clark
H.Merijn Brand
1. A lot of work for Configure. We know that most gcc builds can do it, but
how can we detect that any non GNU compiler can?
2. It they can't, you will imply a huge peformance loss, which IMHO is
unacceptable. For example perl compiled with native HP C-ANSI-C is about
25% percent faster than when built with gcc. This is for many people a
reason to buy the expensive HP C compiler. We cannot just throw that gain
into the trash can
> Nicholas Clark
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Nicholas Clark
Compile test programs. I'm not asking you to write them. I'm thinking
about pinching parrot's :-)
> 2. It they can't, you will imply a huge peformance loss, which IMHO is
> unacceptable. For example perl compiled with native HP C-ANSI-C is about
> 25% percent faster than when built with gcc. This is for many people a
> reason to buy the expensive HP C compiler. We cannot just throw that gain
> into the trash can
For now I was talking about stuff where there is already a special case for
gcc. So I believe we lose nothing changing this gcc specific code to inline
[assuming that all gcc we ever meet can inline]
And may gain somewhat if we can find an easy way to solve 1.
But even without solving 1, we can fix bugs in the gcc paths.
Nicholas Clark
David Nicol
> For now I was talking about stuff where there is already a special case for
> gcc. So I believe we lose nothing changing this gcc specific code to inline
> [assuming that all gcc we ever meet can inline]
>
> And may gain somewhat if we can find an easy way to solve 1.
> But even without solving 1, we can fix bugs in the gcc paths.
>
> Nicholas Clark
This may be a naive question, but is the only advantage of
inlining over macro definition that the local variable names
are hidden, and other niceties of calling syntax?
--
david nicol "I'll be working, working; but if you come visit I'll
put down what I'm doing: my friends are important" -- David Byrne
Nicholas Clark
> On Mon, 2003-12-01 at 17:06, Nicholas Clark wrote:
>
> > For now I was talking about stuff where there is already a special case for
> > gcc. So I believe we lose nothing changing this gcc specific code to inline
> > [assuming that all gcc we ever meet can inline]
> >
> > And may gain somewhat if we can find an easy way to solve 1.
> > But even without solving 1, we can fix bugs in the gcc paths.
> >
> > Nicholas Clark
>
> This may be a naive question, but is the only advantage of
> inlining over macro definition that the local variable names
> are hidden, and other niceties of calling syntax?
Yes, and debuggers ought to be able to happier with real functions
(macros are hell in symbolic debuggers)
But hiding local variable names is enough for me :-)
Nicholas Clark
Enache Adrian
> Yes, and debuggers ought to be able to happier with real functions
> (macros are hell in symbolic debuggers)
Try gcc -g3 -gdwarf-2 and a recent (current?) gdb.
As of inline functions, sorry, but I don't think it's a good idea.
(compilers may support the keyword, but it's just a noop, they
inline only when they see fit (no debugging switches, not too
much inlining), you should use 'static inline' with gcc, etc, etc)
Regards,
Adi
Stas Bekman
> On Mon, Dec 01, 2003 a.d., Nicholas Clark wrote:
>
>>Yes, and debuggers ought to be able to happier with real functions
>>(macros are hell in symbolic debuggers)
>
>
> Try gcc -g3 -gdwarf-2 and a recent (current?) gdb.
More details can be found here, btw:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_10.html#SEC69
http://perl.apache.org/docs/2.0/devel/debug/c.html#Expanding_C_Macros_with_C_gdb_
There is also a way to use pre-processor make target to expand macros:
http://perl.apache.org/docs/2.0/devel/debug/c.html#Expanding_C_Macros_with_C_make_
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:st...@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Chip Salzenberg
> SV *nsv = (SV*)(sv); \
> ...
>
> They should use uglier names for their local variables (ex. __nsv,
> or even better __SvREFCNT_dec_nsv :-)).
In ISO C and C++, symbols that start with underscores are reserved for
the implementation (the compiler and standard libraries). It's a Very
Bad Idea for a programmer to use names with leading underscores if he
can at all avoid it. A workable prefix is "PL_", or perhaps "PL__";
which of these you like will depend on whether you think the "PL_na"
precedent is good or bad.
--
Chip Salzenberg - a.k.a. - <ch...@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
Chip Salzenberg
> As of inline functions, sorry, but I don't think it's a good idea.
I'm with Enache. Perl has to be so extraordinarily portable, any
inline function would a macro twin; that's just extra work for us,
not improvement.
Rafael Garcia-Suarez
> According to Enache Adrian:
> > SV *nsv = (SV*)(sv); \
> > ...
> >
> > They should use uglier names for their local variables (ex. __nsv,
> > or even better __SvREFCNT_dec_nsv :-)).
>
> In ISO C and C++, symbols that start with underscores are reserved for
> the implementation (the compiler and standard libraries).
I thought this was only symbols that match /^_[A-Z_]/ ?
Chip Salzenberg
> Chip Salzenberg wrote:
> > In ISO C and C++, symbols that start with underscores are reserved for
> > the implementation (the compiler and standard libraries).
>
> I thought this was only symbols that match /^_[A-Z_]/ ?
Well, kinda. Your question prompted me to RTFM, and it turns out I
was doubly wrong for C++; leading underscores can be safe, but "PL__"
is not! ISO C++89, section 17.4.3.1.2, says:
* Each name that _contains_ a double underscore (__) or _begins_
with an underscore followed by an upper-case letter is reserved to
the implementation for any use. [emphasis added]
* Each name that begins with an underscore is reserved to the
implemenation for use as a name in the global namespace.
Anybody have the relevant passages from the ISO C standard? Most of
Perl's compilations are still in C, not C++, and the rules may be just
different enough to matter.
Gisle Aas
> Anybody have the relevant passages from the ISO C standard?
I don't have the standard but I believe the information in [1] is
close. It goes:
| In addition to the names documented in this manual, reserved names
| include all external identifiers (global functions and variables)
| that begin with an underscore (`_') and all identifiers regardless
| of use that begin with either two underscores or an underscore
| followed by a capital letter are reserved names. This is so that the
| library and header files can define functions, variables, and macros
| for internal purposes without risk of conflict with names in user
| programs.
|
| Some additional classes of identifier names are reserved for future
| extensions to the C language or the POSIX.1 environment. While using
| these names for your own purposes right now might not cause a
| problem, they do raise the possibility of conflict with future
| versions of the C or POSIX standards, so you should avoid these
| names.
|
| * Names beginning with a capital `E' followed a digit or
| uppercase letter may be used for additional error code
| names. See section Error Reporting.
|
| * Names that begin with either `is' or `to' followed by a
| lowercase letter may be used for additional character testing
| and conversion functions. See section Character Handling.
|
| * Names that begin with `LC_' followed by an uppercase letter
| may be used for additional macros specifying locale
| attributes. See section Locales and Internationalization.
|
| * Names of all existing mathematics functions (see section
| Mathematics) suffixed with `f' or `l' are reserved for
| corresponding functions that operate on float and long double
| arguments, respectively.
|
| * Names that begin with `SIG' followed by an uppercase letter
| are reserved for additional signal names. See section Standard
| Signals.
|
| * Names that begin with `SIG_' followed by an uppercase letter
| are reserved for additional signal actions. See section Basic
| Signal Handling.
|
| * Names beginning with `str', `mem', or `wcs' followed by a
| lowercase letter are reserved for additional string and array
| functions. See section String and Array Utilities.
|
| * Names that end with `_t' are reserved for additional type
| names.
[1] http://www.gnu.org/manual/glibc-2.2.3/html_chapter/libc_1.html#SEC12
Nick Ing-Simmons
>On Mon, Dec 01, 2003 a.d., Nick Ing-Simmons wrote:
>>
>> Tk804.025_beta6 under blead was failing because it had
>...
>> SvREFCNT_dec(nsv);
>...
>> If I rename it nmsv it works.
>
>Some macros using the gcc 'blocks in parens' extension
>are quite naive.
>
>Example:
>#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && !defined(PERL_GCC_PEDANTIC)
># define SvREFCNT_dec(sv) \
> ({ \
> SV *nsv = (SV*)(sv); \
> ...
Hmm, why did I not get bitten by this pre bleadperl ?
But thanks for spotting it.
Nick Ing-Simmons
>On Mon, 2003-12-01 at 17:06, Nicholas Clark wrote:
>
>> For now I was talking about stuff where there is already a special case for
>> gcc. So I believe we lose nothing changing this gcc specific code to inline
>> [assuming that all gcc we ever meet can inline]
>>
>> And may gain somewhat if we can find an easy way to solve 1.
>> But even without solving 1, we can fix bugs in the gcc paths.
>>
>> Nicholas Clark
>
>This may be a naive question, but is the only advantage of
>inlining over macro definition that the local variable names
>are hidden, and other niceties of calling syntax?
It also makes it easier on the compiler spotting duplicate code,
and avoids side effects issues if one was fool enough to write
SvPV(sv++) or similar.
Horsley Tom
> >inlining over macro definition that the local variable names
> >are hidden, and other niceties of calling syntax?
There is one gigantic advantage of inlines over macros: When debugging,
you can usually step into inlines and what what is going on, with
macros (in most debuggers I have seen, anyway), the body of the
macro is totally obscure to the debugger.
Chip Salzenberg
sigils (or namespaces (but that way lay C++)).
Anyway, it looks like auto var names in macros can be safely prefixed
with a single underscore, e.g. "_nsv", to avoid name conflicts with
surrounding code.
H.Merijn Brand
from perlhack.pod:
=head2 gdb macro support
Recent versions of F<gdb> have fairly good macro support, but
in order to use it you'll need to compile perl with macro definitions
included in the debugging information. Using F<gcc> version 3.1, this
means configuring with C<-Doptimize=-g3>. Other compilers might use a
different switch (if they support debugging macros at all).
Nicholas Clark
> According to Enache Adrian:
> > As of inline functions, sorry, but I don't think it's a good idea.
>
> I'm with Enache. Perl has to be so extraordinarily portable, any
> inline function would a macro twin; that's just extra work for us,
> not improvement.
Do you see any harm in taking our existing twin definition messes and
turning the gcc branch into an inline? Here's an example:
#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && !defined(PERL_GCC_PEDANTIC)
# define SvREFCNT_inc(sv) \
({ \
SV *nsv = (SV*)(sv); \
if (nsv) \
ATOMIC_INC(SvREFCNT(nsv)); \
nsv; \
})
#else
# ifdef USE_5005THREADS
# if defined(VMS) && defined(__ALPHA)
# define SvREFCNT_inc(sv) \
(PL_Sv=(SV*)(sv), (PL_Sv && __ATOMIC_INCREMENT_LONG(&(SvREFCNT(PL_Sv)))), (SV *)PL_Sv)
# else
# define SvREFCNT_inc(sv) sv_newref((SV*)sv)
# endif
# else
# define SvREFCNT_inc(sv) \
((PL_Sv=(SV*)(sv)), (PL_Sv && ATOMIC_INC(SvREFCNT(PL_Sv))), (SV*)PL_Sv)
# endif
#endif
Nicholas Clark
Chip Salzenberg
> Do you see any harm in taking our existing twin definition messes and
> turning the gcc branch into an inline?
I do see some harm, enough to make it not worth the trouble.
1. Speed hit - the extra semantics of function calls aren't free.
Functions are call-by-value and return-by-value, even when they're
inlined. This means extra copying, thus extra register spills.
It's been a while since I've looked at the output of gcc's function
inlining code, but back then it was really ugly, and the basic
issues haven't changed, so it's probably bad enough to avoid.
2. Semantic changes - if gcc uses inlines and others don't, that means
that some unsuspecting programmer will be writing SvIV(*svp++) in
his XS code and it'll work for him and all his Linux buddies and all
the rest of the gcc users. Everyone else will have weird breakage.
That's pretty evil.
3. Symbol table issues - depending on our debugging options, might we
need the functions to be outlined? If so, we'll need to designate
a victim source file to trigger the outlining. This may not apply.
Chip Salzenberg
> According to Nicholas Clark:
> > Do you see any harm in taking our existing twin definition messes and
> > turning the gcc branch into an inline?
>
> I do see some harm, enough to make it not worth the trouble.
> 2. Semantic changes [...]
> 3. Symbol table issues [...]
Allow me to add:
4. All parameters are read-only. Some macros assign to their parameters.
In C, inline functions can't do that. They can modify through pointers,
but those pointers are strictly typed, so e.g. SvPV() could not be
written as an inline function in C.
h...@crypt.org
:According to Nicholas Clark:
:> Do you see any harm in taking our existing twin definition messes and
:> turning the gcc branch into an inline?
:
:I do see some harm, enough to make it not worth the trouble.
:
:1. Speed hit - the extra semantics of function calls aren't free.
: Functions are call-by-value and return-by-value, even when they're
: inlined. This means extra copying, thus extra register spills.
:
: It's been a while since I've looked at the output of gcc's function
: inlining code, but back then it was really ugly, and the basic
: issues haven't changed, so it's probably bad enough to avoid.
I last looked at such output a few years ago, and it seemed fine then.
I'd like to see some figures for the cost if you're convinced.
:2. Semantic changes - if gcc uses inlines and others don't, that means
: that some unsuspecting programmer will be writing SvIV(*svp++) in
: his XS code and it'll work for him and all his Linux buddies and all
: the rest of the gcc users. Everyone else will have weird breakage.
: That's pretty evil.
I think you're talking here about the potential that a macro could read
its argument more than once when the inline function doesn't. In Nick's
example, at least, the three variant macro definitions do not read their
argument more than once, and in general we strongly recommend against
any macro being defined that does so.
One of the benefits of writing in function style is that it takes no
effort to avoid such double-reads.
Hugo
Chip Salzenberg
> Chip Salzenberg <ch...@pobox.com> wrote:
> :1. Speed hit - the extra semantics of function calls aren't free.
> : Functions are call-by-value and return-by-value, even when they're
> : inlined. This means extra copying, thus extra register spills.
>
> I'd like to see some figures for the cost if you're convinced.
Hm. OK. No promises when, though.
> :2. Semantic changes - if gcc uses inlines and others don't, that means
> : that some unsuspecting programmer will be writing SvIV(*svp++) ...
>
> I think you're talking here about the potential that a macro could read
> its argument more than once when the inline function doesn't.
Or less than once.
> One of the benefits of writing in function style is that it takes no
> effort to avoid such double-reads.
That pesky call-by-value again.