jima@hplsla.HP.COM ( Jim Adcock) (01/27/88)
This is kind of restating mdt's comments at the C++ workshop, but it seems like
an awful shame that you can't get the same kind of control over "this" as
other passed parameters to C++ functions. For example in:
A::d() {this->a(); this->b(); this->c();};
whatever C++ compiler you're using is going to have to assume that a(), b(),
and c(), could have modified the value of "this", so for example, after
a() is called, the compiler is going to have to generate code to reload
"this" into a register, then use "this" to load "this"'s vtable pointer
into a register, then use the vtable pointer offset to load the address
of b into a register, then jump to subroutine b ....
then it has repeat the whole process again after b() is called in order
to call c()......
whereas if a() and b() could declare that they don't change "this", then
the whole process of loading "this" into a register, then using "this"
to get the vtable pointer, etc would only have to be done once.
What if C++ allowed [but did not require] "this" to be explicetly declared
as "const" or "reference" in the declaration of a member function?
[Don't ask me what the syntax would be, maybe just explicetely declared as
if the first parameter in the passed parameter list]
Seems like there are a LOT of situations where a compiler could generate
much better code if it just could be told that "this" is not modified in
the called member functions.jima@hplsla.HP.COM ( Jim Adcock) (02/02/88)
In response to the vast amount of excitment this note has generated, let me say I am tending to rethink this subject. Per conversations with MTD and Glen Purdy here, it should be possible to use a variety of register passing schemes for "this' and the "vtable" pointer that will avoid most inefficiencies, even if the called routine is unable to declare (this*) const or not. Ideally, this, and this->vtable are passed to the called (virtual) routine using a register passing scheme. The called routine knows whether vtable gets poisoned by an assignment to (this*) and can update vtable accordingly before it exits. PS: If you are a c++ compiler writer, I sure would lobby for the idea of passing "this" and "this->vtable" using a register passing scheme. This would not invalidate existing C libraries using a stack passing scheme for "normal" variables, since C++ "this" and "this->vtable" are NOT "normal" variables, nor do they have an equivalent in normal C code. I guess this "this" register passing scheme could even be faked-up in cfront if anyone were so motivated.
archiel@mntgfx.mentor.com (Archie Lachner) (02/10/88)
in article <6590015@hplsla.HP.COM>, jima@hplsla.HP.COM ( Jim Adcock) says: > > In response to the vast amount of excitment this note has generated, > let me say I am tending to rethink this subject. Per conversations > with MTD and Glen Purdy here, it should be possible to use a variety > of register passing schemes for "this' and the "vtable" pointer that > will avoid most inefficiencies, even if the called routine is unable > to declare (this*) const or not. > > Ideally, this, and this->vtable are passed to the called (virtual) > routine using a register passing scheme. The called routine knows > whether vtable gets poisoned by an assignment to (this*) and can > update vtable accordingly before it exits. Efficiency issues aside, it would be nice to have some mechanism by which one could specify which member functions were legal for use with constant objects and which were legal only for non-constants. For example, it is not now currently possible to specify that the member function "operator=()" should not be applied to constants. The mechanism of optionally specifying "this" as an argument to a member function could conceivably be used to solve this problem. -- Archie Lachner Mentor Graphics Corporation Beaverton, Oregon ...!{decwrl,sequent,tessi}!mntgfx!archiel
bs@alice.UUCP (02/11/88)
Archie Lachner from Mentor Graphics Corporation writes > Efficiency issues aside, it would be nice to have some mechanism by which > one could specify which member functions were legal for use with constant > objects and which were legal only for non-constants. For example, it is > not now currently possible to specify that the member function "operator=()" > should not be applied to constants. The mechanism of optionally specifying > "this" as an argument to a member function could conceivably be used to solve > this problem. I don't think that there is an efficiency issue (that is, there may be an issue over the efficiency of a given implementation - cfront output is only as efficient as the equivalent C, it could be more efficient - but there is no need for new language features to support even further speedups), but there certainly is a need to review the relation between ``const objects'' and member functions. I'm not yet quite sure how to deal with that issue. Ideas?
jima@hplsla.HP.COM ( Jim Adcock) (02/19/88)
| I don't think that there is an efficiency issue (that is, there may | be an issue over the efficiency of a given implementation - cfront | output is only as efficient as the equivalent C, it could be more | efficient - but there is no need for new language features to support | even further speedups). Well, my original comments were made in regard to ultimate 68020 code I've seen generated from C++ routines that do something like this aClasss::vfunction() { this->vfunc1(); this->vfunc2(); this->vfunc3(); } and the ultimate code generated by the various combinations of cfront, cc gcc and g++ all seem to end up with the same problem, namely that "this" and "this->vtable" are being reloaded into register every time after a vfuncX() is called. And given that *this could be overridden in any of the vFuncX() what other code could a compiler generate? -- unless you have a compiler that generates metacode which is not turned into actual machine code during the link process? And even then I have a hard time imagining that the optimization process is really going to discover whether or not *this gets clobbered in a given vFuncX(); So my only thought was if there was someway to state a given vfuncX() DOES NOT clobber *this then this and this->vtable would only have to be loaded into registers once at the start of vfunction, and thereafter calling a vfuncX() would only entail an indirect-with-offset function call. Seems like an efficiency issue to me.
serge@asgard.uucp (serge) (02/27/88)
In article <6590018@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >So my only thought was if there was someway to state a given vfuncX() DOES >NOT clobber *this then this and this->vtable would only have to be loaded >into registers once at the start of vfunction, and thereafter calling a >vfuncX() would only entail an indirect-with-offset function call. This issue (and others) could be addressed if the method definition/invocation syntax was method(x, y, z ...); instead of x.method(y, z ...); This would have the advantage that + one could specify attributes of `this' (const, reference, etc.) + there would no longer be a need for `this' keyword + syntax would be simpler and more uniform (method == overload) + it would allow for multiply polymorphic methods (!)
leech@unc.cs.unc.edu (Jonathan Leech) (02/27/88)
Expires: Sender: Followup-To: Distribution: Keywords: In article <23134@ucbvax.BERKELEY.EDU> serge@berkeley.edu (serge) writes: > This issue (and others) could be addressed if the method >definition/invocation syntax was > method(x, y, z ...); >instead of > x.method(y, z ...); Except you can no longer distingush a global function func(complex,int) and a member function complex::func(int) The overloading mechanism could not distingush these, nor could the programmer. Jon Leech (leech@cs.unc.edu) __@/ ``After all, the best part of a holiday is perhaps not so much to be resting yourself as to see all the other fellows busy working.'' - Kenneth Grahame, _The Wind in the Willows_