[CVS ci] mmd_vtable 9 - remove bxor vtable entry
Leopold Toetsch
The dispatch for the C<bxor> PMC opcodes is now down fully per MMD.
The MMD_BXOR and MMD_BXOR_INT MMD slots are just adjacent entries in the
function table. This is the simplest implementation and provides good
cache locality for similar functions.
I think it's now time to review the code a bit and check if the whole
concept is sane.
Interesting is the dispatch inside objects. These have a delegate vtable
which runs a PASM function. But it could be redispatched before by
installing an appropriate MMD version.
Finally we should probably rename the VTABLE_<function> macros to e.g.
DISPATCH_<function> which is either the current vtable call or the
mmd_dispatch_<signature>(... ,MMD_<type>) function. --Or provide two
sets of macros, i.e. have additionally MMD_DISPATCH_<function> macros?
See classes/ref.pmc for a current workaround and include/parrot/vtable.h
for the current macros.
leo
Dan Sugalski
>Things start to get interesting. The first two vtable slots are
>gone. The dispatch for the C<bxor> PMC opcodes is now down fully per
>MMD.
>
>The MMD_BXOR and MMD_BXOR_INT MMD slots are just adjacent entries in
>the function table. This is the simplest implementation and provides
>good cache locality for similar functions.
>
>I think it's now time to review the code a bit and check if the
>whole concept is sane.
Looks OK.
>Interesting is the dispatch inside objects. These have a delegate
>vtable which runs a PASM function. But it could be redispatched
>before by installing an appropriate MMD version.
I think we're going to want to think about this some. What was the
basic vtable dispatch function that got delegated is now going to be
the default function for the object, and I think we can leave it at
that.
It does mean that we're going to need to get the notification system
in so we can catch updates to the namespaces. I'll split the event/IO
doc I'm working on into pieces and get that out so we can hit this
next.
>Finally we should probably rename the VTABLE_<function> macros to e.g.
>DISPATCH_<function> which is either the current vtable call or the
>mmd_dispatch_<signature>(... ,MMD_<type>) function. --Or provide two
>sets of macros, i.e. have additionally MMD_DISPATCH_<function>
>macros?
>See classes/ref.pmc for a current workaround and
>include/parrot/vtable.h for the current macros.
I think going with the DISPATCH_<function> macros is the way to go for this.
It all looks just fine, so I'm all for whacking it in for the rest of
the vtable slots and getting this done in one go.
After that maybe we can beat ICU into submission and cut a 0.1.1 release. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> At 1:36 PM +0200 5/10/04, Leopold Toetsch wrote:
>>I think it's now time to review the code a bit and check if the
>>whole concept is sane.
> Looks OK.
Fine.
>>Interesting is the dispatch inside objects. These have a delegate
>>vtable which runs a PASM function. But it could be redispatched
>>before by installing an appropriate MMD version.
> I think we're going to want to think about this some. What was the
> basic vtable dispatch function that got delegated is now going to be
> the default function for the object, and I think we can leave it at
> that.
> It does mean that we're going to need to get the notification system
> in so we can catch updates to the namespaces. I'll split the event/IO
> doc I'm working on into pieces and get that out so we can hit this
> next.
Objects need still further work, initializer, finalizers, and the
TODO diamond inheritance test (hint, hint :)
>>Finally we should probably rename the VTABLE_<function> macros to e.g.
>>DISPATCH_<function>
> I think going with the DISPATCH_<function> macros is the way to go for this.
Yes. Simplifies .ops file writing a bit.
> It all looks just fine, so I'm all for whacking it in for the rest of
> the vtable slots and getting this done in one go.
I won't have much time, 2 conferences here in Austria in the next 2
weeks.
So if someone wants to have a look at patches mmd_vtables 9 and 10 just
go ahead. The only missing bits are the general DISPATCH_<function> macro
and some dispatch function prototypes. The rest should be more or less
some cut'n'paste work.
> After that maybe we can beat ICU into submission and cut a 0.1.1 release. :)
Yep. When these nasty ICU build issues are sorted out, then its 0.1.1
time.
Thanks for looking through it,
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
> > At 1:36 PM +0200 5/10/04, Leopold Toetsch wrote:
>
>>>Interesting is the dispatch inside objects. These have a delegate
>>>vtable which runs a PASM function. But it could be redispatched
>>>before by installing an appropriate MMD version.
>
>> I think we're going to want to think about this some. What was the
>> basic vtable dispatch function that got delegated is now going to be
>> the default function for the object, and I think we can leave it at
>> that.
>
>> It does mean that we're going to need to get the notification system
>> in so we can catch updates to the namespaces. I'll split the event/IO
>> doc I'm working on into pieces and get that out so we can hit this
>> next.
>
>Objects need still further work, initializer, finalizers, and the
>TODO diamond inheritance test (hint, hint :)
I know, I know... :) I'll get to those in a little bit.
> > It all looks just fine, so I'm all for whacking it in for the rest of
>> the vtable slots and getting this done in one go.
>
>I won't have much time, 2 conferences here in Austria in the next 2
>weeks.
>
>So if someone wants to have a look at patches mmd_vtables 9 and 10 just
>go ahead. The only missing bits are the general DISPATCH_<function> macro
>and some dispatch function prototypes. The rest should be more or less
>some cut'n'paste work.
I'll take a look at it. Turns out I need it working in the next few
days, so it's only fair that I actually make it work.
> > After that maybe we can beat ICU into submission and cut a 0.1.1
>release. :)
>
>Yep. When these nasty ICU build issues are sorted out, then its 0.1.1
>time.
Woo! And, I expect, Hoo! Then the fun will really begin.