Re: mmd for bitwise_and causes a segfault with my pmc types

It seems to work in general, but in some cases (especially when I allocate too much memory) it causes me a segfault or an error like: Trace/breakpoint trap (core dumped) It was caused by some unitialized memory in src/mmd.c. rt #43105 solves it. -- Mehmet

Re: MMD roundup 2 - TODO and design items

Rather than adding another file, I'd recommend putting these under DESIGN in docs/ROADMAP. Then they're all in one place for Chip when he gets more tuits. I added a link to this one there. Regards. On Jul 25, 2005, at 10:53 AM, Leopold Toetsch wrote: Nicholas Clark wrote: This all g

Re: MMD roundup 2 - TODO and design items

Nicholas Clark wrote: This all got Warnocked, didn't it? Having read it twice, I don't think I'm going to get closer to a decent response than "er, this is really a call for the designer to make, isn't it?" Mway be it's time to start a WARNOCKED file in parrot's root dir and collect such und

Re: MMD roundup 2 - TODO and design items

On Mon, Apr 18, 2005 at 12:15:34PM +0200, Leopold Toetsch wrote: > Below is some stuff, which I'm unsure of how it should be implemented > eventually. Input is highly welcome. > TODO items and design issues > > 1) bitwise or, and, xor > > We currently have two distinct sets of opcodes and MMD

Re: mmd

Jeff Horwitz wrote: [ mmd test code ] the pmc version of bar() is never called, even when passing a PMC. This is fixed now. A differing argument count had a too low distance penalty. But please note that the MMD system still has no clue what is an invocant and what a plain call argument bec

Re: mmd

[ cc'ed list ] Chip Salzenberg wrote: On Tue, May 24, 2005 at 02:42:47PM -0400, Jeff Horwitz wrote: .sub bar method, @MULTI(Foo, pmc) At first blush, I think mmd based on representation choice ($I vs. $P) is a mistake. Why should an integer in a $P0 be mmd'd differently from an integer in

Re: mmd

On Tue, 24 May 2005, Leopold Toetsch wrote: > Multi subs and especially multi methods are barely tested. 'pmc' or '_' > should match 'Any' PMC, so that's for sure a bug. Can you please provide > a test-like sample file to investigate, thanks. here you go. it should print "string PMC nothing", bu

Re: mmd

Jeff Horwitz wrote: for mod_parrot i want to support both passing both PMCs and native types to the apache API, depending on the HLL. MMD was doing a great job handling this for me until i ran into a problem. given the following methods: .sub bar method, @MULTI(Foo, string) .sub bar method, @M

Re: MMD leftover: logical_{or,and,xor}

Patrick R. Michaud wrote: On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote: So the right thing for the logical functions seems to be, to just return the left or right side according to their boolean value (or return a new Boolean false in case of xor), i.e. you get a reference to o

Re: MMD leftover: logical_{or,and,xor}

On Wed, May 11, 2005 at 10:17:30AM +0200, Leopold Toetsch wrote: > > So the right thing for the logical functions seems to be, to just return > the left or right side according to their boolean value (or return a new > Boolean false in case of xor), i.e. you get a reference to one of the > PMCs

Re: MMD acting up...

Cory Spencer <[EMAIL PROTECTED]> wrote: > I've encountered some multimethod dispatch funnyness tonight. The > included code which one would expect to produce a value of 1 ends up > printing a value of 3. It wasn't really a MMD problem, but the already described problem of an Integer being either

Re: MMD roundup 2 - TODO and design items

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > TODO items and design issues And some more: 6) stringish MMD infix operators: concatenate, repeat The implementation takes either two strings, or one string and an integer repeat count. Again not much multi to dispatch IMHO. Missing: PMC variants of

Re: MMD roundup 2 - TODO and design items

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > 5) new opcodes that return a new result: > Px = n_add Py, Pz # new Px created > These opcodes will be done RSN. RSN is now. There is one basic test in t/pmc/integer.t. Overloading is tested in mmd.t. More tests are welcome for other PMCs. Cav

Re: MMD as an object.

[EMAIL PROTECTED] wrote: Ok. If you'd really need such random dispatch, it could be done like this, when I interpret A12 correctly: sub run_random_bar($x) { my @meths = WALKMETH($x, :method('bar')); my $meth = @meths[rand(@meths.elems)]; $meth($x); } or even with my sub bar($x) {...}

Re: MMD as an object.

Leopold Toetsch wrote: Rod Adams <[EMAIL PROTECTED]> wrote: It seems to me that there are several advantages to making a group of multi with the same short name a single object, of type MultiSub|MultiMethod, which internally holds references to the all the various routines that share that short

Re: MMD as an object.

Rod Adams <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >>Discussion seems to have went off into esoteric cases of locally >>overriden dispatcher policies and what not. > I don't think it's as esoteric as you might think. Consider: > package Foo; > use MMD::Random; > our &bar

Re: MMD as an object.

Bob Rogers <[EMAIL PROTECTED]> wrote: >From: Leopold Toetsch <[EMAIL PROTECTED]> >1) is there a MultiSub object with one short name that holds all >possible long names (and function references)? >If yes, who is creating it: the Perl6 compiler emits code to do so or >it's up to

Re: MMD as an object.

From: Leopold Toetsch <[EMAIL PROTECTED]> Date: Thu, 10 Mar 2005 10:53:11 +0100 Rod Adams <[EMAIL PROTECTED]> wrote: > It seems to me that there are several advantages to making a group of > multi with the same short name a single object, of type > MultiSub|MultiMethod, which int

Re: MMD as an object.

[EMAIL PROTECTED] wrote: What about multi subs? They can be defined everywhere. Given: multi sub *foo(A $a, B $b) {...} Is this something like: %globals{"foo"} --> MultiSub{"foo_A_B" => Sub, ...} What about a not so global multi: multi sub foo(A $a, B $b) {...} Thanks for clarifying, leo Uh

Re: MMD as an object.

Rod Adams <[EMAIL PROTECTED]> wrote: > It seems to me that there are several advantages to making a group of > multi with the same short name a single object, of type > MultiSub|MultiMethod, which internally holds references to the all the > various routines that share that short name. Discussion

Re: MMD and VTABLE_find_method

Sam Ruby wrote: I took your example code, almost word for word, and added approximately three, count them three, machine instructions (not Parrot instructions, not C statements, but machine instructions) to the path length, and now adjectives like "horribly slow and wierd" come out. It looks li

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: pmclass default abstract noinit { PMC* add (PMC* left, PMC* right) { PRESERVE_CONTEXT; add_func = mmd_find("__add"...) // via VTABLE_find_method and here it becomes horribly slow and weird. You are already in one "add". What do you want t

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: PyStringPyIntPyNum Integer ... -- PyString py_add_sadd_err add_err add_err PyInt add_err add_i add_n add_i PyNum add_err add_n add_n add_i

Re: MMD and VTABLE_find_method

Sam Ruby wrote: [ a lot - I'll split answers ] Leopold Toetsch wrote: Sam Ruby wrote: It seems obvious, but it leads to surprises. Example: '1' + '2' The result will depend on what the actual types are of the inputs perhaps even what the context is of the caller. Ehem, given that and ... (from

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: First, a few things to note: the semantics of "add" vary from language to language. In particular, add is not guaranteed to be commutative in Python (think string addition). Yes, of course. It seems obvious, but it leads to surprises. Example: '1' + '2'

Re: MMD and VTABLE_find_method

Sam Ruby writes: > In the general case, a call to a subroutine with three arguments can > have four possibilities: anywhere from zero to three arguments may be > involved in the dispatch. > > I also read this to say that whatever code is generated by a subroutine > call is independent of the nu

Re: MMD and VTABLE_find_method

Hi, a lurker here. Probably you forgot the braces: > + /* let's ignore the complexities of a distance_func for now... */ > + mmd_flag = 0; > + addsub = VTABLE_find_method(INTERP, $1, __add, 0, &mdd_flag); > + if (!addsub) { > + mmd_flag = 0; > + adds

Re: MMD and VTABLE_find_method

Sam Ruby wrote: First, a few things to note: the semantics of "add" vary from language to language. In particular, add is not guaranteed to be commutative in Python (think string addition). Yes, of course. As my proposal is primarily focused on where the logic is placed in the system, not how i

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: First, a direct quote from : Please let's stay at the basics. Please describe your counter proposal for a very elementary add Px, Py, Pz operation. There's really no need to procede to Perl6 objects,

Re: MMD and VTABLE_find_method

Sam Ruby wrote: First, a direct quote from : Please let's stay at the basics. Please describe your counter proposal for a very elementary add Px, Py, Pz operation. There's really no need to procede to Perl6 objects, if we can't even find

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: A "foo" PMC could represent an entire row in a two dimensional MMD, or an entire plane in a three dimensional MMD, ... etc. What does it mean: "represent a row..."? What about the namespace pollution? Again: where does this hypothetica

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: A "foo" PMC could represent an entire row in a two dimensional MMD, or an entire plane in a three dimensional MMD, ... etc. What does it mean: "represent a row..."? What about the namespace pollution? Again: where does this hypothetical MMD PMC come from? A

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: A few things to note: "foo" is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can "know" how many arguments are involved in multiple dispatch. The MMD information can't hang off the Sub PMCs.

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: A few things to note: "foo" is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can "know" how many arguments are involved in multiple dispatch. The MMD information can't hang off the Sub PMCs. How do you find the co

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: However, from : Whenever you make a call using subroutine call syntax, it's a candidate for multiple dispatch. I read this to mean that the *caller* does nothing to distingu

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: However, from : Whenever you make a call using subroutine call syntax, it's a candidate for multiple dispatch. I read this to mean that the *caller* does nothing to distinguish between calls to si

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: Sam Ruby wrote: Leopold Toetsch wrote: The caller sets: mmd_flag := NULL ... no MMD, plain method lookup mmd_flag := &depth ... return the next matching method starting at the given parent search depth In the general case, how does the ca

Re: MMD and VTABLE_find_method

Sam Ruby wrote: Leopold Toetsch wrote: The caller sets: mmd_flag := NULL ... no MMD, plain method lookup mmd_flag := &depth ... return the next matching method starting at the given parent search depth In the general case, how does the caller know that MMD is i

Re: MMD and VTABLE_find_method

Leopold Toetsch wrote: 2) n-dimensional MMD Perl6 supports a more general form of MMD: multi sub foo(ClassA $a, ClassB $b, ClassC $c : ...) { ... } [snip] 4) Proposed changes: a) All method lookup goes through VTABLE_find_method. To achieve MMD functionality, two arguments are added to the find_

Re: MMD problem with mmd_dispatch_v_pnp

Jens Rieks <[EMAIL PROTECTED]> wrote: > Hi! > I have found a problem with with mmd_dispatch_v_pnp. > The function calls (for an Integer-PMC) Parrot_Integer_multiply_int, which > expects an INTVAL, but a FLOATVAL is passed to it. I can't reproduce that. new P1, .Integer set P1, 2 new P2, .U

Re: MMD: more implications

Sam Ruby <[EMAIL PROTECTED]> wrote: > General thoughts on the proposal to replace VTABLES with methods: > 1) Anything that is unary (i.e., contains exactly or one argument) is > not affected by MMD. That's not quite true. We currently have just infix MMD dispatching on left and right. That's just

Re: MMD: more implications

General thoughts on the proposal to replace VTABLES with methods: 1) Anything that is unary (i.e., contains exactly or one argument) is not affected by MMD. There is no need to replace any such methods. 2) While I don't see Python translators using a "sin" opcode, I can see the implementation o

Re: MMD dispatch

Leopold Toetsch <[EMAIL PROTECTED]> wrote: > ... We can deal > with performance implications later. I've googled for »MMD "polymorphic inline cache"«: 1-2 of about 3 on perl6-internals archives. You might guess the author of these mail ;) leo

Re: MMD table setup semantics

At 3:35 PM +0100 5/27/04, Nicholas Clark wrote: On Wed, Apr 28, 2004 at 06:36:34PM -0400, Dan Sugalski wrote: At 2:56 PM -0700 4/28/04, Larry Wall wrote: >On Wed, Apr 28, 2004 at 05:20:53PM -0400, Dan Sugalski wrote: >: The second question is "if we do, how do we figure which method is >: clos

Re: MMD table setup semantics

On Wed, Apr 28, 2004 at 06:36:34PM -0400, Dan Sugalski wrote: > At 2:56 PM -0700 4/28/04, Larry Wall wrote: > >On Wed, Apr 28, 2004 at 05:20:53PM -0400, Dan Sugalski wrote: > >: The second question is "if we do, how do we figure which method is > >: closest?" > >: > >: Personally I'm of the geomet

Re: MMD & objects

Dan Sugalski <[EMAIL PROTECTED]> wrote: > If we do that it means every PMC class is essentially a base type as > far as Parrot's concerned. Basically yes. We just borrow some functions from parents to avoid reimplementation and to reduce code size. I don't think that we need much more inside the

Re: MMD & objects

At 9:39 AM +0200 5/18/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: The question isn't whether they *do*--rather it's whether they *should*. The current implementation's not all that relevant except as a demonstration of one set of semantics. What I want to do is work out w

Re: MMD & objects

Dan Sugalski <[EMAIL PROTECTED]> wrote: > The question isn't whether they *do*--rather it's whether they > *should*. The current implementation's not all that relevant except > as a demonstration of one set of semantics. What I want to do is work > out what the 'proper' semantics ultimately should

Re: MMD & objects

At 5:54 PM +0200 5/17/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: The basics of MMD are almost done. The two things we still need to deal with are: *) Inherited methods *) Objects ... Either way we need to build up the tables so inherited MMD methods actually get inhe

Re: MMD & objects

Dan Sugalski <[EMAIL PROTECTED]> wrote: > The basics of MMD are almost done. The two things we still need to > deal with are: > *) Inherited methods > *) Objects > ... Either way we need to build up > the tables so inherited MMD methods actually get inherited. MMD registration "inherits" as much

Re: MMD stuff

At 10:48 AM -0700 5/14/04, Jeff Clites wrote: On May 14, 2004, at 9:04 AM, Dan Sugalski wrote: Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the st

Re: MMD stuff

On May 14, 2004, at 9:04 AM, Dan Sugalski wrote: Today's project is to get all the MMD things actually using MMD. I've put in the first wave of changes (well, OK, second if you consider Leo's BXOR test as the first) and should get the rest of the stuff in today. This part's a bit hackish but,

Re: MMD performance

Leopold Toetsch <[EMAIL PROTECTED]> wrote: [ another MMD performance compare ] Just an update. Last benchmark still called MMD via the vtable. Here is now a compare of calling MMD from the run loop: $ parrot -C mmd-bench.imc vtbl add PerlInt PerlInt 1.072931 vtbl add PerlInt Integer 1.085116 M

Re: MMD and/or vtable inconsistencies

At 10:39 AM +0200 4/30/04, Leopold Toetsch wrote: - There is only an is_equal vtable but an MMD_STREQ define and default function - {eq,ne}_{str,num} opcodes are using VTABLE_cmp, which is fine but could be inefficient especially for strings - cmp/cmp_num is handled by the same MMD slot Yeah, we

Re: MMD table setup semantics

At 9:37 AM -0400 4/29/04, William Coleda wrote: Leopold Toetsch wrote: - TclInt - TclFloat - TclObject - TclString This is a small subset of PMCs enumerating *current* scalars. I can't imagine that e.g. tcl is happy, when a tcl scalar falls back to a morphing variant of a Perl scalar. OTOH just do

Re: MMD table setup semantics

Leopold Toetsch wrote: - TclInt - TclFloat - TclObject - TclString This is a small subset of PMCs enumerating *current* scalars. I can't imagine that e.g. tcl is happy, when a tcl scalar falls back to a morphing variant of a Perl scalar. OTOH just doing the math operations would be fine. So wha

Re: MMD performance

Aaron Sherman <[EMAIL PROTECTED]> wrote: > Good stuff! One thing leaps to mind when you mention the cache though... > keep in mind that blowing L2 cache (which we might be in no danger of > doing at all, but I'm just bringing it up) might be WORSE than you would > think on P4 and beyond because of

Re: MMD performance (was: keyed vtables and mmd)

On Thu, 2004-04-29 at 03:33, Leopold Toetsch wrote: > As Dan already said there is no performance hit (at least if the MMD > tables don't blow the caches). Good stuff! One thing leaps to mind when you mention the cache though... keep in mind that blowing L2 cache (which we might be in no danger o

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: >>cc1: Invalid option `-falign-functions=8' > The manpage made it sound like it was an absolute thing, but I can > see it being a power-of-two number. GCC 3.3.3 likes the 8, so I > hadn't noticed. I've a =3 build going now--if it tests OK I'll commit > the

Re: MMD and PASM subs

At 7:12 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: And just to add extra evil, now it works. Seems that gcc does *not* align function pointers by default. Almost: $ perl Configure.pl --maintainer --floatval=double --verbose-step=Determ ... cc1: Invalid optio

Re: MMD and PASM subs

At 7:08 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Oh, right, and... this is really, really evil. Which is why I just put it in. :) *g* Should I cleanup and implement the rest? And which opcode of the (duplicated? mm* ops? I'll go patch this up. I'm halfway

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: > And just to add extra evil, now it works. Seems that gcc does *not* > align function pointers by default. Almost: $ perl Configure.pl --maintainer --floatval=double --verbose-step=Determ ... cc1: Invalid option `-falign-functions=8' This one want -malign

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: > Oh, right, and... this is really, really evil. Which is why I just > put it in. :) *g* Should I cleanup and implement the rest? And which opcode of the (duplicated? mm* ops? leo

Re: MMD and PASM subs

At 4:54 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: Another long running discussion: do we need duplicate mmd tables. Dunno. Don't care, really--I was throwing in two tables as proof-of-concept just to get thi

Re: MMD and PASM subs (was: keyed vtables and mmd)

At 11:42 AM -0400 4/29/04, Dan Sugalski wrote: At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: Another long running discussion: do we need duplicate mmd tables. Here is a proof of concept to avoid it: Oh, right, and... this is really, really evil. Which is why I just put it in. :) And just to add

Re: MMD and PASM subs

Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: >> >>Another long running discussion: do we need duplicate mmd tables. > Dunno. Don't care, really--I was throwing in two tables as > proof-of-concept just to get things going. As there can be just one entr

Re: MMD and PASM subs (was: keyed vtables and mmd)

At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: Another long running discussion: do we need duplicate mmd tables. Here is a proof of concept to avoid it: Oh, right, and... this is really, really evil. Which is why I just put it in. :) -- Dan --

Re: MMD and PASM subs (was: keyed vtables and mmd)

At 3:55 PM +0200 4/29/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Okay, we've a long-running discussion between Leo and I about the keyed variants for all the binary vtable entries. Another long running discussion: do we need duplicate mmd tables. Dunno. Don't care, really

Re: MMD table setup semantics

Dan Sugalski <[EMAIL PROTECTED]> wrote: > Personally I'm of the geometric distance school here, but it can get > a bit tricky, so I'm all for discussion on it. So... let's have at > it. :) If you can provide a distance table for these PMCs: - PerlUndef - PerlInt - PerlNum - PerlString - Integer -

Re: MMD table setup semantics

At 2:56 PM -0700 4/28/04, Larry Wall wrote: On Wed, Apr 28, 2004 at 05:20:53PM -0400, Dan Sugalski wrote: : The first question is... *should* we synthesize anything at all? I'd : argue yes, but at this level I can see it going either way. Probably, in general. It's the equivalent of a method cache

Re: MMD backwards compatibility

At 5:43 PM -0400 4/28/04, Dan Sugalski wrote: Since we really ought to have it, as I don't think we want to bother messing around with what we have already in the PMCs, and it's useful in those cases where folks want to write a single override version and install it as a default... Oh, right, co

Re: MMD table setup semantics

On Wed, Apr 28, 2004 at 05:20:53PM -0400, Dan Sugalski wrote: : The first question is... *should* we synthesize anything at all? I'd : argue yes, but at this level I can see it going either way. Probably, in general. It's the equivalent of a method cache. But maybe some people will want to take

Re: MMD vtable functions in bytecode

At 10:24 PM +0200 3/29/04, Leopold Toetsch wrote: Dan Sugalski wrote: At 8:16 PM +0200 3/29/04, Leopold Toetsch wrote: Did you consider ussng PMCs as instead of plain function pointers. As outlined a NCI, C, and PASM Sub PMC would be equally just invoke()d. Yeah, I did. You end up with a twofo

Re: MMD vtable functions in bytecode

At 10:28 PM +0200 3/29/04, Leopold Toetsch wrote: Dan Sugalski wrote: [ cvs ci library/vtable_constants.pasm ] Isn't working IMHO. C<.const int ..> is PIR syntax. *And* that file could be easily auto-created like almost all inside F Ah, damn, that's what I get for not double-checking my working

Re: MMD vtable functions in bytecode

Dan Sugalski wrote: [ cvs ci library/vtable_constants.pasm ] Isn't working IMHO. C<.const int ..> is PIR syntax. *And* that file could be easily auto-created like almost all inside F leo

Re: MMD vtable functions in bytecode

Dan Sugalski wrote: At 8:16 PM +0200 3/29/04, Leopold Toetsch wrote: Did you consider ussng PMCs as instead of plain function pointers. As outlined a NCI, C, and PASM Sub PMC would be equally just invoke()d. Yeah, I did. You end up with a twofold problem there--not only do you have extra indir

Re: MMD vtable functions in bytecode

At 9:40 PM +0200 3/29/04, Leopold Toetsch wrote: Dan Sugalski wrote: You've got me confused here. Well, the question is: Is it allowed to create a continuation in one subroutine with the destination label being in a different subroutine? Oh, OK. Erm. No. Mostly. Subs must be considered self-co

Re: MMD vtable functions in bytecode

Dan Sugalski wrote: You've got me confused here. Well, the question is: Is it allowed to create a continuation in one subroutine with the destination label being in a different subroutine? .sub _f1 label = get_addr dest_label _f2(label) ... dest_label: .end .sub _f2 .param int

Re: MMD vtable functions in bytecode

At 11:12 AM +0100 3/27/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: [ mmd functions ] Another question: ,--[ pdd15 ]-- |While vtable methods may take a continuation, those |continuations may not escape the

Re: MMD vtable functions in bytecode

At 10:29 AM -0800 3/29/04, chromatic wrote: On Mon, 2004-03-29 at 10:23, Dan Sugalski wrote: Ultimately it ought to be doable to have the JIT, on JIT capable systems, construct custom C function headers which means we could skip the second table *and* not bother with PMCs or anything equally f

Re: MMD vtable functions in bytecode

On Mon, 2004-03-29 at 10:23, Dan Sugalski wrote: > Ultimately it ought to be doable to have the JIT, > on JIT capable systems, construct custom C function headers which > means we could skip the second table *and* not bother with PMCs or > anything equally fat for the function entries. Would b

Re: MMD vtable functions in bytecode

At 8:40 AM +0100 3/27/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: So, I'm doing these, because I need 'em, and we might as well get the things in now. For the record, these things will be called as functions (not methods), with three parameters, so the signature looks lik

Re: MMD vtable functions in bytecode

At 8:16 PM +0200 3/29/04, Leopold Toetsch wrote: Dan Sugalski wrote: At 8:40 AM +0100 3/27/04, Leopold Toetsch wrote: A short question WRT implementation: shouldn't all MMD functions just use one function slot? You now seem to duplicate the whole table. Yes, I do. Did you consider ussng PMCs as

Re: MMD vtable functions in bytecode

Dan Sugalski wrote: At 8:40 AM +0100 3/27/04, Leopold Toetsch wrote: A short question WRT implementation: shouldn't all MMD functions just use one function slot? You now seem to duplicate the whole table. Yes, I do. Did you consider ussng PMCs as instead of plain function pointers. As outlined

Re: MMD vtable functions in bytecode

Dan Sugalski <[EMAIL PROTECTED]> wrote: [ mmd functions ] Another question: ,--[ pdd15 ]-- |While vtable methods may take a continuation, those |continuations may not escape the vtable method's |execution. This is due to

Re: MMD vtable functions in bytecode

Dan Sugalski <[EMAIL PROTECTED]> wrote: > So, I'm doing these, because I need 'em, and we might as well get the > things in now. For the record, these things will be called as > functions (not methods), with three parameters, so the signature > looks like: A short question WRT implementation: shou

Re: MMD (was This week's summary)

On Mon, 09 Jun 2003, Mark A. Biggar wrote: multi factorial (0) { 1 } multi factorial ($n) { $n * factorial($n - 1) } That's a bad example, as it's really not MMD. It's a partially pre-memoized function instead. It is MMD as long as the dispatching mechanism (of the language or the engine it runs o