On Thu, 3 Aug 2000, Nick Ing-Simmons wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 05:39 PM 8/2/00 +0100, Tim Bunce wrote:
> >>On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote:
> >> >
> >> > Reference counting is going to be a fun one, that's for sure.
> >> >
> >> > I'd like
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 05:39 PM 8/2/00 +0100, Tim Bunce wrote:
>>On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote:
>> >
>> > Reference counting is going to be a fun one, that's for sure.
>> >
>> > I'd like the interface to be something like:
>> >
>> >stat = pe
At 05:39 PM 8/2/00 +0100, Tim Bunce wrote:
>On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote:
> >
> > Reference counting is going to be a fun one, that's for sure.
> >
> > I'd like the interface to be something like:
> >
> >stat = perl_get_value(sv *, int what, &destination)
>
>And
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >> I don't think so - it is a question which way we code the source:
> >>
> >> A. Use 'inline' every where and trust compiler not to do what we told it
> >>if it knows better.
> >> B. No inline hints in th
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >> That sounds like a pre-judgement that inline form is prefered ;-)
> >> But actually most places (I looked when doing TIEARAY) perl itself calls
> >> nether it uses AvFILL() macro instead.
> >
> >As I understa
John Tobey <[EMAIL PROTECTED]> writes:
>> I don't think so - it is a question which way we code the source:
>>
>> A. Use 'inline' every where and trust compiler not to do what we told it
>>if it knows better.
>> B. No inline hints in the source and trust the compiler to be able to
>>do
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Tim Bunce <[EMAIL PROTECTED]> writes:
> >
> >Perl5 XS/GUTS is the way it is largely because it was designed with
> >performance in mind.
>
> Hmm, maybe in some areas but not others:
> On the one hand the whole PUTBACK/SPAGAIN mess is by overly clev
John Tobey <[EMAIL PROTECTED]> writes:
>> That sounds like a pre-judgement that inline form is prefered ;-)
>> But actually most places (I looked when doing TIEARAY) perl itself calls
>> nether it uses AvFILL() macro instead.
>
>As I understand myself, AvFILL == i_av_fill, so thank you for
>confir
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> Brent Fulgham <[EMAIL PROTECTED]> writes:
> >The 'inline' keyword is just a hint to the compiler. If optimization
> >is turned off, no inlining is done. If optimization is on, the
> >compiler may or may not decide to inline. Performance on different
Tim Bunce <[EMAIL PROTECTED]> writes:
>
>Perl5 XS/GUTS is the way it is largely because it was designed with
>performance in mind.
Hmm, maybe in some areas but not others:
On the one hand the whole PUTBACK/SPAGAIN mess is by overly clever
attempt to optimize access to "global" variables whic
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >> Bad assumption. How often is av_fill called?
> >
> >Only once in av_fill.c (generated by allfuncs.pl). In most other
> >places, it's called as i_av_fill().
>
> Tha
Brent Fulgham <[EMAIL PROTECTED]> writes:
>> > Having thought about it a bunch more (because of this) I'm
>> > proposing we let the compiler decide. The caller doesn't
>> > know enough to make that decision.
>>
>> Read carefully. I said we *let* the caller decide, not *make* the
>> caller dec
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'll point out here that I, for one, don't mind people deciding to head out
> and do a port/reimplement/rewrite on their own. I won't promise that your
> work (whoever you are in that sentence) will go into the 'official' perl
Thanks, that's all I ask.
John Tobey <[EMAIL PROTECTED]> writes:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> Bad assumption. How often is av_fill called?
>
>Only once in av_fill.c (generated by allfuncs.pl). In most other
>places, it's called as i_av_fill().
That sounds like a pre-judgement that inline form is prefered ;
On Wed, Aug 02, 2000 at 05:39:19PM +0100, Tim Bunce wrote:
> On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote:
> >
> > Reference counting is going to be a fun one, that's for sure.
> >
> > I'd like the interface to be something like:
> >
> >stat = perl_get_value(sv *, int what,
On Wed, Aug 02, 2000 at 12:05:20PM -0400, Dan Sugalski wrote:
>
> Reference counting is going to be a fun one, that's for sure.
>
> I'd like the interface to be something like:
>
>stat = perl_get_value(sv *, int what, &destination)
And what type is perl_get_value declared as returning?
I c
At 12:01 PM 8/2/00 +0100, Andy Wardley wrote:
>Nick:
> > PUSHMARK;
> > XPUSHs(sv_2mortal(newSVpv('DeepThought'));
> > XPUSHs(sv_2mortal(newSViv(42));
> > PUTBACK;
> > count = perl_call_method("Consider",G_EVAL);
> > SPAGAIN;
> > if (count >= 1) {
> > answer = SvIV(POPs));
> > }
> >
> >You _want_
On Wed, Aug 02, 2000 at 11:11:32AM -0400, Andy Dougherty wrote:
> On Wed, 2 Aug 2000, Tim Bunce wrote:
>
> > Perl5 XS/GUTS is the way it is largely because it was designed with
> > performance in mind. I think Larry did a very good job. My only big
> > worry for perl6 is that, without great care
At 04:22 PM 8/2/00 +0900, Simon Cozens wrote:
>But even on purely selfish grounds,
>that's a very dumb idea - walking away from a community and forking its
>project is a really good way to get yourself hated, fast. (Ask Theo DeRaadt
>some time...)
I'll point out here that I, for one, don't mind p
On Wed, 2 Aug 2000, Tim Bunce wrote:
> Perl5 XS/GUTS is the way it is largely because it was designed with
> performance in mind. I think Larry did a very good job. My only big
> worry for perl6 is that, without great care, we'll loose that
> performance edge in the name of a 'clean API'.
Anoth
Tim Bunce <[EMAIL PROTECTED]> wrote:
> So please, follow Chips wise lead, don't call your work Perl 6.
It's called Pickle.
"Andy Wardley" <[EMAIL PROTECTED]> wrote:
> Indeed. XS is hard, fast, dirty and ugly (in a sickly, beautiful
> kinda way), but there's nothing to stop you from wrapping it
Tim Bunce <[EMAIL PROTECTED]> wrote:
> There may be scope for having two levels of API. One high level clean
> simple etc and the other a lower-level more performance oriented API.
> The former could be implemented in terms of the latter.
This is essentially what I meant by:
inline i_foo() {
Nick:
> PUSHMARK;
> XPUSHs(sv_2mortal(newSVpv('DeepThought'));
> XPUSHs(sv_2mortal(newSViv(42));
> PUTBACK;
> count = perl_call_method("Consider",G_EVAL);
> SPAGAIN;
> if (count >= 1) {
> answer = SvIV(POPs));
> }
>
>You _want_ to keep that???
Tim:
> There may be scope for having two levels of
On Tue, Aug 01, 2000 at 06:10:53PM -0400, John Tobey wrote:
> Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> > By all means have a go at Topaz-II
> >
> > But it won't be 'Perl 6' unless it implements what perl-language
> > decides that _is_.
>
> Agreed. It won't even remotely resemble 'Perl 6'
On Tue, Aug 01, 2000 at 10:30:36PM -0400, Dan Sugalski wrote:
> At 06:23 PM 8/1/00 -0400, John Tobey wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > At 09:43 PM 8/1/00 +, Nick Ing-Simmons wrote:
> > > >Nor am I sure that the XS API is not one of the things I would not
> > > >have near
On Wed, Aug 02, 2000 at 02:47:25AM -0400, John Tobey wrote:
> The schedule is just to get something down, to start fleshing out my
> idea and maybe provoke other people into starting on their own
> visions, as Simon Cozens has (though he seems to deny it) done with
> GLib and Sapphire.
Oh boy. On
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > The people here are rightly skeptical about the effectiveness of using
> > the 5.6 code base as a starting point for v6, but I have a pretty
> > clear vision of how to do it, and I am committed to giving it a try,
On Tue, 1 Aug 2000, John Tobey wrote:
> The people here are rightly skeptical about the effectiveness of using
> the 5.6 code base as a starting point for v6, but I have a pretty
> clear vision of how to do it, and I am committed to giving it a try,
> even if no one else will. In fact, I'll give
At 06:35 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 05:55 PM 8/1/00 -0400, John Tobey wrote:
> > >Dan, you are completely missing my point. Okay, fine, non-inline may
> > >be a performance win in some cases. Inline may be a win in others. I
> > >am not pr
At 06:44 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Bad assumption. How often is av_fill called?
>
>Only once in av_fill.c (generated by allfuncs.pl). In most other
>places, it's called as i_av_fill().
Nope. In perl 6, the internal and external APIs will be v
At 06:23 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 09:43 PM 8/1/00 +, Nick Ing-Simmons wrote:
> > >Nor am I sure that the XS API is not one of the things I would not
> > >have near top of the list for "internals cleanup":
> > >
> > >PUSHMARK;
> > >XPUSH
[EMAIL PROTECTED] wrote:
> John Tobey wrote:
>
> > > Why is he bothering? A year to produce a prototype doesn't seem like a
> > > useful way to expend effort on something that isn't actually perl6.
> >
> > It is actually perl6 if/when it's finished.
>
> Right, so it isn't a community effort th
John Tobey wrote:
> > Why is he bothering? A year to produce a prototype doesn't seem like a
> > useful way to expend effort on something that isn't actually perl6.
>
> It is actually perl6 if/when it's finished.
Right, so it isn't a community effort then, as you intend doing it all
yourself.
Nick Ing-Simmons wrote:
> I have said this before but the gist of the Nick-theory is:
>
> Page boundaries are a don't care unless there is a page miss.
> Page misses are so costly that everything else can be ignored,
> but for sane programs they should only be incured at "startup".
> (Reducing c
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> >> But is usually much easier add entropy - so start with its the same
> >> function - call it, and let compiler decide which ones to expand.
> >
> >You'll get no
John Tobey <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
>> But is usually much easier add entropy - so start with its the same
>> function - call it, and let compiler decide which ones to expand.
>
>You'll get no argument on that point. Please stop suggesting that I
>
> > Having thought about it a bunch more (because of this) I'm
> > proposing we let the compiler decide. The caller doesn't
> > know enough to make that decision.
>
> Read carefully. I said we *let* the caller decide, not *make* the
> caller decide. What, specifically, disturbs you about my
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Bad assumption. How often is av_fill called?
Only once in av_fill.c (generated by allfuncs.pl). In most other
places, it's called as i_av_fill().
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:34 PM 8/1/00 -0400, John Tobey wrote:
> >Okay. For starters, assume that every inline function is called in
> >exactly one place in the translation unit that defines its non-inline
> >counterpart. That one place being, of course, i_foo's foo. This
> > I think you may have missed the context of the message.
> > John was talking about creating his Alpha using various
> > existing projects that had already been done in C++.
>
> Why is he bothering? A year to produce a prototype doesn't
> seem like a useful way to expend effort on somethi
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:55 PM 8/1/00 -0400, John Tobey wrote:
> >Dan, you are completely missing my point. Okay, fine, non-inline may
> >be a performance win in some cases. Inline may be a win in others. I
> >am not proposing we mandate inlining in any case, I am proposi
Alan Burlison <[EMAIL PROTECTED]> wrote:
> Brent Fulgham wrote:
>
> > > I think there is an undiscussed assumption about the implementation
> > > language in there somewhere...
> >
> > I think you may have missed the context of the message. John was talking
> > about creating his Alpha using va
At 05:34 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > ) Compaq C
> > will do it differently depending on the number of times that the inlined
> > function is used.
>
>Okay. For starters, assume that every inline function is called in
>exactly one place in the tr
At 05:55 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > >Non-inline functions have their place in reducing code size
> > > > >and easing debugging. I just want an i_foo for every foo that callers
> > > > >will have the option of using.
> > > >
> > > > Before w
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> But is usually much easier add entropy - so start with its the same
> function - call it, and let compiler decide which ones to expand.
You'll get no argument on that point. Please stop suggesting that I
want to take the power of decision away from
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 09:43 PM 8/1/00 +, Nick Ing-Simmons wrote:
> >Nor am I sure that the XS API is not one of the things I would not
> >have near top of the list for "internals cleanup":
> >
> >PUSHMARK;
> >XPUSHs(sv_2mortal(newSVpv('DeepThought'));
> >XPUSHs(sv_2morta
Brent Fulgham wrote:
> > I think there is an undiscussed assumption about the implementation
> > language in there somewhere...
>
> I think you may have missed the context of the message. John was talking
> about creating his Alpha using various existing projects that had already
> been done in
John Tobey <[EMAIL PROTECTED]> writes:
>> Maybe not for void functions with no args, tail-called and with
>> no prefix, but in more typically cases yes it can be different
>> the "function-ness" of i_foo applies constaints on where args
>> and "result" are which optimizer _may_ not be able to unr
At 09:43 PM 8/1/00 +, Nick Ing-Simmons wrote:
>Nor am I sure that the XS API is not one of the things I would not
>have near top of the list for "internals cleanup":
>
>PUSHMARK;
>XPUSHs(sv_2mortal(newSVpv('DeepThought'));
>XPUSHs(sv_2mortal(newSViv(42));
>PUTBACK;
>count = perl_call_method("C
Brent Fulgham <[EMAIL PROTECTED]> wrote:
> > Alan Burlison wrote:
> >
> > John Tobey wrote:
> >
> > > 1 November 2000 - Perl6 alpha in C++ that uses classes derived
> > >from PerlInterpreter and SV
> > everywhere in place
> > >of these types,
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> By all means have a go at Topaz-II
>
> But it won't be 'Perl 6' unless it implements what perl-language
> decides that _is_.
Agreed. It won't even remotely resemble 'Perl 6' (as opposed to Perl
5) until it's in a position to start changing the lex
Alan Burlison <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
>
> > 1 November 2000 - Perl6 alpha in C++ that uses classes derived
> >from PerlInterpreter and SV everywhere in place
> >of these types, a la Pickle, but with inline
> >
> Alan Burlison wrote:
>
> John Tobey wrote:
>
> > 1 November 2000 - Perl6 alpha in C++ that uses classes derived
> >from PerlInterpreter and SV
> everywhere in place
> >of these types, a la Pickle, but with inline
> >m
John Tobey <[EMAIL PROTECTED]> writes:
>The people here are rightly skeptical about the effectiveness of using
>the 5.6 code base as a starting point for v6, but I have a pretty
>clear vision of how to do it, and I am committed to giving it a try,
>even if no one else will. In fact, I'll give you
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > >Non-inline functions have their place in reducing code size
> > > >and easing debugging. I just want an i_foo for every foo that callers
> > > >will have the option of using.
> > >
> > > Before we make any promises to do all that extra work can we
>
John Tobey wrote:
> 1 November 2000 - Perl6 alpha in C++ that uses classes derived
>from PerlInterpreter and SV everywhere in place
>of these types, a la Pickle, but with inline
>methods that use Perl 5's internal API.
At 05:21 PM 8/1/00 -0400, John Tobey wrote:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> > John Tobey <[EMAIL PROTECTED]> writes:
> > >Is foo() compiled any differently in
> > >
> > >inline i_foo() { BLA; BLA; BLA; }
> > >foo() { i_foo(); }
> > >
> > >versus
> > >
> > >foo() { BLA; B
On Tue, Aug 01, 2000 at 08:55:09PM +, [EMAIL PROTECTED] wrote:
> >Non-inline functions have their place in reducing code size
> >and easing debugging. I just want an i_foo for every foo that callers
> >will have the option of using.
>
> Before we make any promises to do all that extra work c
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:55 PM 8/1/00 -0400, John Tobey wrote:
> >Well, I am going to assume you are wrong and the above two foo()
> >implementations will produce exactly the same code.
>
> Your assumption is incorrect for good compilers. (Whether gcc counts as
> good for
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I'm thinking of a rewrite in the sense that (by my impression) BSD was
> > a rewrite of Unix. Refactoring, shifting stuff around until it's easy
> > to get a handle on things, and replace it all a little at a tim
At 04:55 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 04:37 PM 8/1/00 -0400, John Tobey wrote:
> > >Is foo() compiled any differently in
> > >
> > > inline i_foo() { BLA; BLA; BLA; }
> > > foo() { i_foo(); }
> > >
> > >versus
> > >
> > > foo() { BL
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> John Tobey <[EMAIL PROTECTED]> writes:
> >Is foo() compiled any differently in
> >
> >inline i_foo() { BLA; BLA; BLA; }
> >foo() { i_foo(); }
> >
> >versus
> >
> >foo() { BLA; BLA; BLA; }
>
> Maybe not for void functions with no args, tail
John Tobey <[EMAIL PROTECTED]> writes:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> (FWIW, it seems on many of the modern
>> processors that inlining code decreases your performance, so I think
>> deciding on stuff like that is rather premature)
>
>Is foo() compiled any differently in
>
>inl
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 04:37 PM 8/1/00 -0400, John Tobey wrote:
> >Is foo() compiled any differently in
> >
> > inline i_foo() { BLA; BLA; BLA; }
> > foo() { i_foo(); }
> >
> >versus
> >
> > foo() { BLA; BLA; BLA; }
> >
> >?
>
> Probably. On many newer chips, the
At 04:37 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > (FWIW, it seems on many of the modern
> > processors that inlining code decreases your performance, so I think
> > deciding on stuff like that is rather premature)
>
>Is foo() compiled any differently in
>
>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> (FWIW, it seems on many of the modern
> processors that inlining code decreases your performance, so I think
> deciding on stuff like that is rather premature)
Is foo() compiled any differently in
inline i_foo() { BLA; BLA; BLA; }
foo() { i_fo
At 02:31 AM 8/1/00 -0400, Sam Tregar wrote:
>I suppose a reasonable question is: can we achieve
>our goals without a rewrite? Can we succeed in integrating threading and
>Unicode where the Perl5 developers have failed, without rewriting the
>internals? I'm not qualified to say no, but I'd like t
On Tue, 1 Aug 2000, John Tobey wrote:
> I'm thinking of a rewrite in the sense that (by my impression) BSD was
> a rewrite of Unix. Refactoring, shifting stuff around until it's easy
> to get a handle on things, and replace it all a little at a time. So,
> yes, these problems can be solved IMHO
OK, this is the last I'll say on it before laying *myself* to rest.
:-)
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 01, 2000 at 02:31:15AM -0400, Sam Tregar wrote:
> > Note that we don't have to take that "chance," but I don't think we should
> > turn it down lightly. I suppose a reaso
On Tue, Aug 01, 2000 at 02:31:15AM -0400, Sam Tregar wrote:
> Note that we don't have to take that "chance," but I don't think we should
> turn it down lightly. I suppose a reasonable question is: can we achieve
> our goals without a rewrite? Can we succeed in integrating threading and
> Unicode
> > Umm, well, not necessarily. Not if what I'm doing becomes what we're
> > doing.
>
> Do tell! What have you been doing?
Well, I don't want everybody looking at it in its current (TEMPORARY!)
shambles, but I posted download instructions to this list in a reply
to Simon.
> I'm not here to t
On Tue, 1 Aug 2000, John Tobey wrote:
> Umm, well, not necessarily. Not if what I'm doing becomes what we're
> doing.
Do tell! What have you been doing?
> See http://joel.editthispage.com/stories/storyReader$47 on the
> evils of total rewrites.
This article has been haunting me. My boss lo
Sam Tregar <[EMAIL PROTECTED]> wrote:
> We need to start with the basics and we need to keep things simple and
> understandable. I get the sense that the perl dev community has more than
> its share of efficiency experts. That's a good thing but there's a proper
> time to optimize and this is no
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Counter-counterproposition: Look at the way Sapphire does it. I'm really
> proud of that. It's automagically switchable from inlines to ordinary
> functions to macros. You can choose which wins, and it's neat to debug.
Hear, hear! This is exactly what I
On Tue, 1 Aug 2000, Simon Cozens wrote:
> Counter-counterproposition: Look at the way Sapphire does it. I'm really
> proud of that. It's automagically switchable from inlines to ordinary
> functions to macros. You can choose which wins, and it's neat to debug.
Counter-counter-... Sure I'll take
On Tue, Aug 01, 2000 at 01:00:15AM -0400, Sam Tregar wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I propose that all internal and external functions be implemented in
> > header files and declared inline. The external runtime API will be
> > generated by compiling non-inline wrappers.
>
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I propose that all internal and external functions be implemented in
> > header files and declared inline. The external runtime API will be
> > generated by compiling non-inline wrappers.
> >
> > This will make
On Tue, 1 Aug 2000, John Tobey wrote:
> I propose that all internal and external functions be implemented in
> header files and declared inline. The external runtime API will be
> generated by compiling non-inline wrappers.
>
> This will make possible an interesting performance optimization wit
I propose that all internal and external functions be implemented in
header files and declared inline. The external runtime API will be
generated by compiling non-inline wrappers.
This will make possible an interesting performance optimization with
GNU CC, whereby op_ppaddr is replaced by a loca
79 matches
Mail list logo
