Do we need to reopen B1?
Christophe de Dinechin
ddd at cup.hp.com
Fri Feb 25 17:50:43 UTC 2000
Jason Merrill wrote:
> > , as long as they are emitted with the corresponding
> > virtual table.
>
> No; this would disallow emitting them with the function, if the function
> and vtable are defined in different places. I don't think we need to
> specify this.
Ooops, you are correct. The sentence should indeed be "as long as they are
emitted whenever the main entry point is emitted."
>
> > An existing compiler which uses thunks could be
> > converted to use this ABI by only adding support for the vcall
> > offsets (in the case of virtual inheritance), and by creating
> > a named entry point and a thunk for each possible adjustment
> > from a secondary base to the derived class (in the case of
> > multiple, non-virtual inheritance).
>
> I don't understand "a named entry point and a thunk". In this case, the
> thunk is the entry point.
The 'entry point' denotes a label with linkage. The 'thunk' denotes the code. I
agree the wording is not that good.
>
> > A more efficient implementation would be to emit all of the
> > adjusting entry points immediately before the non-adjusting
> > entry point to the function. Such thunks can also be combined
> > in the form of multiple 'Add' instructions that fall through
> > to the main entry point.
>
> You used 'thunk'. :)
Ooops.
>
> > Another implementation yet is to use
> > predication rather than branches to reach the main function
> > [Note: I'm not sure this actually works without a calling
> > convention on predicates...].
>
> I had been thinking about something like
>
> foo:
> add *p
> set predicate
> bar:
> [if not set] add *q
> ...
>
> but I'd be perfectly happy to lose the predication language.
>
> Jason
The problem is that you can't go to 'bar' unless you know that the predicate is
not set. That's what I called a "calling convention on predicates". Something
like "p777 is always reset at the time a virtual call branch is made", where
p777 would be part of the ABI.
Regards
Christophe
More information about the cxx-abi-dev
mailing list