eAt 04:57 PM 8/15/00 +0100, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >How much of the current base of target ports are you willing to give up in
> >the first cut for fast? The TIL suggestion, amongst others, has the
> >potential to speed things up rather a lot, but i
Dan Sugalski wrote:
> Okay, now I'm confused. I was under the impression that doing a TIL really
> required getting down 'n dirty with assembly-level jmps and jsrs, the
> alternative being the op-loop we've got now, more or less.
I think that's true if we're threading Perl functions. TIL assumes
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>How much of the current base of target ports are you willing to give up in
>the first cut for fast? The TIL suggestion, amongst others, has the
>potential to speed things up rather a lot, but it has the disadvantage of
>requiring intimate knowledge of ea
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>A TIL level sub
>
> ^TIL header code# ptr to real Function
> ^funcA # Start of a til function
> ^funcB # start of a til function
> ^funcC
>
>So all pointers point at a real function. In the
Chaim Frenkel writes:
: > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
:
: LW> On the other hand, targeting JVM and IL.NET might keep us honest enough.
:
: What is IL.NET?
Sorry, just my shorthand for the IL of .NET, which is to say, Microsoft's
new intermediate language.
Larry
On Tue, Aug 15, 2000 at 09:47:05AM -0400, Chaim Frenkel wrote:
> > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
>
> LW> On the other hand, targeting JVM and IL.NET might keep us honest enough.
>
> What is IL.NET?
Perhaps the perl6 web pages should have a list of 'required readings' URLs.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> A TIL doesn't have to be machine code. A first pass for a port that does
>> the TIL inner loop in C, should be quite portable.
DS> Okay, now I'm confused. I was under the impression that doing a TIL really
DS> required getting down 'n di
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> On the other hand, targeting JVM and IL.NET might keep us honest enough.
What is IL.NET?
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED]
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> How much of the current base of target ports are you willing to
DS> give up in the first cut for fast? The TIL suggestion, amongst
DS> others, has the potential to speed things up rather a lot, but it
DS> has the disadvantage of r
On 14 Aug 2000, Chaim Frenkel wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> How much of the current base of target ports are you willing to give up in
> DS> the first cut for fast? The TIL suggestion, amongst others, has the
> DS> potential to speed things up rather a l
On Mon, 14 Aug 2000, Larry Wall wrote:
> Dan Sugalski writes:
> : On Mon, 14 Aug 2000, Larry Wall wrote:
> :
> : > Dan Sugalski writes:
> : > : The big problem here is the large number of operators that need to
> : > : be supported in every vtable. On the other hand, it means we whittle
> : > :
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> How much of the current base of target ports are you willing to give up in
DS> the first cut for fast? The TIL suggestion, amongst others, has the
DS> potential to speed things up rather a lot, but it has the disadvantage of
DS> requiring
Dan Sugalski writes:
: On Mon, 14 Aug 2000, Larry Wall wrote:
:
: > Dan Sugalski writes:
: > : The big problem here is the large number of operators that need to
: > : be supported in every vtable. On the other hand, it means we whittle
: > : ourselves down to only one operator opcode. ;-)
: >
:
On Mon, 14 Aug 2000, Larry Wall wrote:
> Dan Sugalski writes:
> : The big problem here is the large number of operators that need to
> : be supported in every vtable. On the other hand, it means we whittle
> : ourselves down to only one operator opcode. ;-)
>
> I don't care if the program is hal
Dan Sugalski writes:
: The big problem here is the large number of operators that need to
: be supported in every vtable. On the other hand, it means we whittle
: ourselves down to only one operator opcode. ;-)
I don't care if the program is half vtables, as long as it runs fast.
Larry
On Mon, 14 Aug 2000, Larry Wall wrote:
> Nick Ing-Simmons writes:
> : >It's not clear to me whether the intrinsic types should have a different
> : >solution to this than the extrinsic types.
> :
> : _This_ thread is about using vtables for intrinsic types. If we cannot
> : make them work there
Nick Ing-Simmons wrote:
> Larry Wall <[EMAIL PROTECTED]> writes:
> >Sure, but we may have to warp our ideas of what a vtable is to encompass
> >the notion of a vtable that is the cross-product of two vtables.
>
> That wouldn't be a 'vector' table but a 'matrix' table ! only 1/2 ;-)
Yep. Multime
Nick Ing-Simmons writes:
: Larry Wall <[EMAIL PROTECTED]> writes:
: >Nick Ing-Simmons writes:
: >: >It's not clear to me whether the intrinsic types should have a different
: >: >solution to this than the extrinsic types.
: >:
: >: _This_ thread is about using vtables for intrinsic types. If we c
Larry Wall <[EMAIL PROTECTED]> writes:
>Nick Ing-Simmons writes:
>: >It's not clear to me whether the intrinsic types should have a different
>: >solution to this than the extrinsic types.
>:
>: _This_ thread is about using vtables for intrinsic types. If we cannot
>: make them work there then t
Nick Ing-Simmons writes:
: >It's not clear to me whether the intrinsic types should have a different
: >solution to this than the extrinsic types.
:
: _This_ thread is about using vtables for intrinsic types. If we cannot
: make them work there then the proposed innermost SV * replacment is flaw
Larry Wall <[EMAIL PROTECTED]> writes:
>
>I was talking about utf8 strings having a completely different vtable
>than a utf16 or a utf32 string. The statement in question seems to be
>incompatible with that, but I'm not here to argue about that.
>
>What I'd like to figure out about these vtables
Chaim Frenkel writes:
: > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
:
: LW> : =item vtable
: LW> :
: LW> : The vtable field holds a pointer to the vtable for a variable. Each
: LW> : variable type has its own vtable, holding pointers to functions for
: LW> : the variable. Vtables are sh
> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
LW> : =item vtable
LW> :
LW> : The vtable field holds a pointer to the vtable for a variable. Each
LW> : variable type has its own vtable, holding pointers to functions for
LW> : the variable. Vtables are shared between variables of the same
L
At 04:26 PM 8/12/00 -0700, Larry Wall wrote:
>[EMAIL PROTECTED] writes:
>: This way perl doesn't, for example, have to know how to access an
>: individual element of an array of integers--it just asks the array to
>: return it a particular element. Code MUST use the vtable functions to
>: get or s
[EMAIL PROTECTED] writes:
: This way perl doesn't, for example, have to know how to access an
: individual element of an array of integers--it just asks the array to
: return it a particular element. Code MUST use the vtable functions to
: get or set values from variables. They MUST NOT directly a
At 08:35 PM 8/6/00 +, Nick Ing-Simmons wrote:
>Ken Fox <[EMAIL PROTECTED]> writes:
> >(And if
> >we say something like "this is fast" people will ignore all the warnings.)
>
>As one of the worst offenders I certainly will ;-)
Works for me. :) People have always had the capability to fundament
Ken Fox <[EMAIL PROTECTED]> writes:
>
>When we document this, can we move the low level interfaces out of the
>pod directory? It would be a shame to have people accidentally start using
>the internal interfaces just because they're well documented. ;)
If they are well documented then the risks t
At 12:51 PM 8/5/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > but it's really not SVs that eat up all the space, it's arrays and hashes.
>
>And closures! If curried functions get added (and they're just sugar for
>closures) we're going to have to optimize them a *lot* more than Perl 5.
What,
Dan Sugalski wrote:
> but it's really not SVs that eat up all the space, it's arrays and hashes.
And closures! If curried functions get added (and they're just sugar for
closures) we're going to have to optimize them a *lot* more than Perl 5.
> Three classes, which is why the three lines here. I
At 12:07 PM 8/5/00 +, Nick Ing-Simmons wrote:
>Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
> >=head1 IMPLEMENTATION
> >
> >The base variable structure looks like:
> >
> >struct {
> > IV GC_data;
> > void *variable_data;
> > IV flags;
> > void *vtable;
> > void
Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
>
>This is similar to the structure used in perl 5, with one major
>difference. Rather than having all the intellegence needed to use a
>variable separate from that variable, this RFC embeds that information
>into the variable itself. This allows for
31 matches
Mail list logo
