[PATCH] vtable_1 - accessor macros
Leopold Toetsch
macros also provides more readable source files:
instead of:
PMC* getprop (STRING* key) {
return ((PMC *)SELF->data)->vtable->getprop(INTERP,
(PMC *)SELF->data, key);
}
this now is:
PMC* getprop (STRING* key) {
return VTABLE_1(getprop, (PMC*) SELF->data, key);
}
If people are ok with this, next step would be actually using these
macros all over the tree.
For reference plz s. also:
Date: Mon, 30 Dec 2002 16:36:31 +0100
From: Leopold Toetsch <l...@toetsch.at>
Subject: Variable/value vtable split
leo
Nicholas Clark
> This is a first step in hiding vtable functions - not only: Using these
> macros also provides more readable source files:
>
> instead of:
>
> PMC* getprop (STRING* key) {
> return ((PMC *)SELF->data)->vtable->getprop(INTERP,
> (PMC *)SELF->data, key);
> }
>
> this now is:
>
> PMC* getprop (STRING* key) {
> return VTABLE_1(getprop, (PMC*) SELF->data, key);
> }
>
> If people are ok with this, next step would be actually using these
> macros all over the tree.
I think that this is a good idea, as it does appear to simplify the C code
considerably, reduce the scope for errors (and cargo cult programming), and
make it easy to change how the vtables are called in future.
However, I'm aware that perl5 goes a very long way down the "use macros" road;
in many people's opinion too far. I don't think that this is too far,
because
1: It's documented what we are doing here
2: It's only 1 layer of macros (not 4 or more, as perl5 can manage)
3: We don't have the cruft of macros no longer needed but kept for source
compatibility cluttering up our header files.
There might be some more rules to try to stick to, but they were the 3 that
were obvious to me.
As these are code generated, are we able to conditionally write these out as
inline functions? This would make debugging easer.
Nicholas Clark
Leopold Toetsch
> On Sun, Mar 23, 2003 at 11:11:54AM +0100, Leopold Toetsch wrote:
>
>>This is a first step in hiding vtable functions - not only: Using these
>>macros also provides more readable source files:
>> return VTABLE_1(getprop, (PMC*) SELF->data, key);
> ..., and
> make it easy to change how the vtables are called in future.
This is the main reason for it.
> 1: It's documented what we are doing here
> 2: It's only 1 layer of macros (not 4 or more, as perl5 can manage)
> 3: We don't have the cruft of macros no longer needed but kept for source
> compatibility cluttering up our header files.
Full ACK.
> As these are code generated, are we able to conditionally write these out as
> inline functions? This would make debugging easer.
Not really, but I don't see, how this set of macros would influence
debugging negatively.
> Nicholas Clark
leo
Jason Gloudon
> Not really, but I don't see, how this set of macros would influence
> debugging negatively.
You can't step through the expanded code for a macro in the debugger.
--
Jason
Leopold Toetsch
> This is a first step in hiding vtable functions - not only: Using these
> macros also provides more readable source files:
While just talking about vtable functions:
- we currently have 259
- 140 of these are some _keyed variants only get/set_{type}_keyed and
defined/exists_keyed are supported by opcodes [1]
- 21 methods are xx_same variants (e.g. bitwise_or_same), which are not
called from anywhere
IMHO vtable.tbl (and default.pmc) need major cleanup.
[1] I think I did already clearly outline, why they can't have distinct
opcodes.
leo
Leopold Toetsch
There is no expanded code, its just a vtable call.
#define VTABLE_0(method, pmc) \
(pmc)->vtable-> ##method## (interpreter, pmc)
#define VTABLE_1(method, pmc, arg1) \
(pmc)->vtable-> ##method## (interpreter, pmc, arg1)
...
leo
Dan Sugalski
>instead of:
>
> PMC* getprop (STRING* key) {
> return ((PMC *)SELF->data)->vtable->getprop(INTERP,
> (PMC *)SELF->data, key);
> }
>
>this now is:
>
> PMC* getprop (STRING* key) {
> return VTABLE_1(getprop, (PMC*) SELF->data, key);
> }
While I'm all for the macros (yeah, I know, debugger stepping issues
and all) I'd rather this be:
VTABLE_getprop(...
rather than
VTABLE_1(getprop,...
because the latter form doesn't give us much of a boost when put
getprop behind a layer of indirection in the vtable, or something
like that.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
>
> While I'm all for the macros (yeah, I know, debugger stepping issues and
> all)
I don't get that. What debugger issues? I changed some vtable calls in
the iterator code and didn't see any differences during debugging. The
macros just rearange the order of function arguments.
> ... I'd rather this be:
>
> VTABLE_getprop(...
>
> rather than
>
> VTABLE_1(getprop,...
>
> because the latter form doesn't give us much of a boost when put getprop
> behind a layer of indirection in the vtable, or something like that.
Well, hmmm - yes. I had this in mind of course (var/value vtable split)
and must have lost the consequencies on they way somewhere :)
Including the vtable method in the macro leaves all the flexibility we
need, in which part of the vtable, the function actually will reside.
And shuffling them around will be easy too.
What about all the currently unused functions. Changing .*vtable.* in
the whole tree seems to be less work, when we concentrate on used code.
If really someone comes up with an efficient scheme of _keyed access
everywhere, we can reinclude them - though I doubt that.
Finally, I had an implicit first argument "interpreter", which possibly
should be in the macros explicitely for more flexiblity.
leo
Kay Roepke
On Sunday, March 23, 2003, at 07:15 PM, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
>> While I'm all for the macros (yeah, I know, debugger stepping issues
>> and all)
>
>
> I don't get that. What debugger issues? I changed some vtable calls in
> the iterator code and didn't see any differences during debugging. The
> macros just rearange the order of function arguments.
I guess this is the same problem debugging perl5 has. If you didn't
build with -g3 and don't have a debugger which supports macro
expansion, you're SOL. Unless of course you could also force the macros
to be inlined functions. But most of the time, you know...
Kay