From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: jason@cygnus.com (Jason Merrill) Cc: jbuck@synopsys.com, dje@watson.ibm.com, law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...) Date: Thu, 26 Aug 1999 17:05:00 -0000 Message-id: <199908270001.RAA27894@atrus.synopsys.com> References: X-SW-Source: 1999-08/msg00908.html Jason writes: > I should point out here that the proposed mechanism is not the classic ARM > vtable. In fact, it doesn't have any more space overhead for single > inheritance code than thunks, and may have less for multiple inheritance > code. It works like this: [ details deleted ] Thanks, Jason, you've removed my objections. My problems were based on the classing scheme, where you have to store offsets for each vtable slot (space overhead) and add the offset during the call (time overhead). I don't quite grasp all of the details on first reading; diagrams would help, but it sounds elegant. (But then it seems that we'll at least temporarily have *three* vtable schemes, sigh). > Rather than per-function offsets, we have per-target type offsets. These > offsets (if any) are stored at a negative index from the vptr. Hmm ... RTTI is currently there, but RTTI takes a fixed # of slots so it's no problem. Joe From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: jason@cygnus.com (Jason Merrill) Cc: jbuck@synopsys.com, dje@watson.ibm.com, law@cygnus.com, mrs@wrs.com, oliva@dcc.unicamp.br, cj@interlog.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: New vtable ABI (was Re: Strange behaviour in C++...) Date: Tue, 31 Aug 1999 23:20:00 -0000 Message-ID: <199908270001.RAA27894@atrus.synopsys.com> References: X-SW-Source: 1999-08n/msg00908.html Message-ID: <19990831232000.smBqv_2ijpH7U1ixSzqJkac2Qeg5RvI1b8kbNngU9z0@z> Jason writes: > I should point out here that the proposed mechanism is not the classic ARM > vtable. In fact, it doesn't have any more space overhead for single > inheritance code than thunks, and may have less for multiple inheritance > code. It works like this: [ details deleted ] Thanks, Jason, you've removed my objections. My problems were based on the classing scheme, where you have to store offsets for each vtable slot (space overhead) and add the offset during the call (time overhead). I don't quite grasp all of the details on first reading; diagrams would help, but it sounds elegant. (But then it seems that we'll at least temporarily have *three* vtable schemes, sigh). > Rather than per-function offsets, we have per-target type offsets. These > offsets (if any) are stored at a negative index from the vptr. Hmm ... RTTI is currently there, but RTTI takes a fixed # of slots so it's no problem. Joe