Path: utzoo!utgpu!water!watmath!clyde!att!ihnp4!poseidon!ech
From: ech@poseidon.UUCP (Edward C Horvath)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Re: 32K jump table limit
Message-ID: <476@poseidon.UUCP>
Date: 29 Aug 88 17:36:24 GMT
References: <3435@Portia.Stanford.EDU>
Organization: AT&T Information Systems, Lincroft, NJ
Lines: 34

> It's not uncommon for units defining fairly sophisticated objects to
> have on the order of 100 method definitions.

> Here's the kicker:  Apple's implementation of method dispatching uses
> a jump table entry for EVERY method, regardless of whether it's only
> called from within the same segment.  4091 is not a large number.  8-(

If all you say is true, you've got BAD trouble...however...

The allocation of jumpTable entries should be a function of the linker, not
the compiler or assembler: i.e. intra-segment calls should not create a
jumpTable entry.  Of course, it only takes one inter-segment call to a
routine to force the routine's entry into the jumpTable.  As a particular
case, if MacApp does dynamic binding through some kind of "central
dispatcher", you're well and truly sunk.  Even using a PACK-like strategy
doesn't help here, since the PACK glue is also 8 bytes a pop, but allocated
from the 32K-limited central dispatcher's CODE segment.  Typical glue:
	move.w	#selector,-(sp)
	jmp	common_entry(a5)

Now, if there ISN'T a central dispatcher, then what you need to do is
what was already suggested: try to group your methods into CODE segments
to reduce inter-segment calls.  In particular, linking offspring classes
into the same segments as their parent classes will reduce inter-segment
calls due to inheritance.

My condolences: this sort of nonsense shouldn't be apparent to the
application designer, particularly in an O-O programming environment.
We groty systems-programming types should be the only ones contending with
such issues.  At least it ain't MS-DOS...

Perhaps Larry Rosenstein (lsr@apple) could shed some light?

=Ned Horvath=