Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!shelby!portia!Jessica!duggie
From: duggie@Jessica.stanford.edu (Doug Felt)
Newsgroups: comp.sys.mac.programmer
Subject: Re: List manager and Think C
Message-ID: <5014@portia.Stanford.EDU>
Date: 1 Sep 89 17:32:26 GMT
References: <5501@viscous.sco.COM> <9389@cadnetix.COM>
Sender: USENET News System <news@Portia.stanford.edu>
Reply-To: duggie@Jessica.UUCP (Doug Felt)
Organization: Stanford University
Lines: 70

In article <9389@cadnetix.COM> pem@cadnetix.COM (Paul Meyer) writes:

>	...  TC4 ONLY offers
>dynamic binding, not static binding.
>
    [description of function overloading omitted]
>
>	The difference between dynamic and static binding is whether inher-
>itance is resolved at compile time or run time.

These statements taken together would seem to imply that TC4 always
goes through the message dispatcher.  Instead, the linker (or
compiler, it's difficult to tell with TC) resolves all the messages it
can into procedure calls.  This turns out to be quite a lot-- all
messages to "inherited" methods (please note I take no position on the
use of this keyword), and all messages with only one implementation,
can be resolved to function calls.  The optimized compile and link in
Apple's Object Pascal does this, among other things.

     [good example of the behavior of virtual functions omitted]

>	... if (foo2->FOO:myfunc())...
>so not allowing static binding doesn't lose any functionality.  It DOES, how-
>ever, lose efficiency in the case where static binding would be sufficient.

Because of this optimizing behavior, I imagine calls such as the one
proposed would be optimized to direct function calls, with no
performance penalty.  I don't have access to the new compiler at work
so haven't tested this.

There are other optimizations that Apple's compiler provides which
may or may not be in TC4.  One is inverting the message tables.  The
idea here is that objects have more messages than messages have objects.
Doing a message lookup on an object is slow, because you may have to
search all of its methods before finding out that the method is 
inherited, and then have to search its superclass's table, etc.  With
inverted tables, you have a table based on the message listing those
classes which implement a method for that message.  Often you only
have to search one or two entries before getting a hit.

Another optimization is caching the last dispatch.  Basically, each
time you get a hit you copy the hit to the a special position in the
table which you always test first.  If a message is mostly going to
the same class then it will hit on the first try.  If inherited
messaging bypasses the dispatch then this cache should be good a lot
of the time, since you rarely message instances of higher-level
classes.

I believe most C++ implementations get around these two by building an
entire dispatch table for each class and indexing into it.  I don't
think TC4 does this.  It seems to index its object descriptions and
method tables off of A5, using object-based dispatch tables and no
cache.  This is probably not so bad since resolving message dispatches
into function calls gets rid of the lion's share of the message tables
and dispatch overhead.

I'm still curious to know what the limits are on the number and sizes
of objects, the number of methods, and so on.  I haven't been able
to find any mention of this, or for that matter, the class 
description and dispatch mechanism, in the manuals.  Perhaps Rich
can help us out.

>Paul Meyer                      pem@cadnetix.COM
>Daisy/Cadnetix Inc. (DAZIX)	{uunet,boulder}!cadnetix!pem
>5775 Flatirons Pkwy.            GEnie P.MEYER
>Boulder, CO 80301               (303)444-8075x277

Doug Felt
Courseware Authoring Tools Project
duggie@jessica.stanford.edu