Path: utzoo!attcan!uunet!samsung!brutus.cs.uiuc.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think C 32K global data limit: workaround?
Message-ID: <5837@internal.Apple.COM>
Date: 18 Dec 89 21:34:08 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 43
References:<257@intek01.UUCP> <1664@cbnewsk.ATT.COM>

In article <1664@cbnewsk.ATT.COM> ech@cbnewsk.ATT.COM (ned.horvath) writes:

> Object Pascal methods went in the (above A5) jump table at 8 bytes a pop,
> another painful limit with even a moderatedly complex class structure.
> I don't know if that latter situation has been corrected; I know there
> was a lot of concern with it at Apple

The problem has been eased somewhat in MacApp 2.0b9, because we always use 
the optimized method dispatching scheme, even when debugging.

Here's a brief explanation of the problem.

In Object Pascal, the method tables contain the A5 offset of the method's 
jump table entry, since that's the most reliable way to store a pointer to 
a routine (which is what you need in the table).  

In addition, you need to assign an ID to each distinct method.  The way we 
do this is to generate a global selector proc and let the linker assign 
the selector proc a jump table entry.  Then the A5 offset becomes the 
method's ID.

With the optimized method dispatching, there's another step to the 
process.  The linker optimizes methods that are never overridden, making 
them exactly the same as a normal procedure call.  It turns out that 75% 
or so of the method in a typical MacApp program fall into this category.

If a method is never overridden, then it doesn't need a selector proc, and 
it needs a jump table entry only if it is called from another segment.  So 
every optmized method saves 1 and possibly 2 jump table entries.

I think people are looking at more permanent solutions to the problem.

> So far, the MPW linker won't give non-apps globals, hence no method 
dispatch
> tables.

See Tech Note #256.  

Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1