Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!jarthur!elroy.jpl.nasa.gov!ames!ads.com!killer!usenet
From: anders@verity.com (Anders Wallgren)
Newsgroups: comp.sys.mac.programmer
Subject: Re: MPW Link problem
Keywords: MPW, Link, MacApp
Message-ID: <1991Jan24.002633.29607@verity.com>
Date: 24 Jan 91 00:26:33 GMT
References: <21614@neptune.inf.ethz.ch>
Sender: usenet@verity.com (USENET News)
Reply-To: anders@verity.com (Anders Wallgren)
Distribution: comp
Organization: Verity, Inc., Mountain View, CA
Lines: 55
In-Reply-To: mueller@inf.ethz.ch (Martin Friedrich Mueller)

In article <21614@neptune.inf.ethz.ch>, mueller@inf (Martin Friedrich Mueller) writes:
>When trying to link a fairly large program including MacApp.lib
>and the MacApp Debugger, I got the following error:
>
>### While reading file "MM-80:MPW:MacApp:Libraries:.Debug Files:MacApp.lib"
>### Link: Error: Number of Jump Table entries exceeds limit of 4092. (Error 108)
>
>What can I do to avoid this limit?
>
>Martin Mueller
>mueller@inf.ethz.ch


You're not going to enjoy this...

Without going into too much detail, you've basically run into a pretty
hard limitation in the current MPW run-time architecture (which is
being addressed in MPW 3.2 - if you don't have ETO#2, get it NOW).
The jump table is used to vector jumps between code in different
segments.  Due to the architecture of the early Macs, there's a limit
on the number of entries in this table (basically, there's an entry
for each subroutine which is called from a routine in another segment,
each one takes up 8 bytes - 8*4092 = 32K = 15bits.  Since the A5
register is used to get at the jump table, and only 16 bits were
available for register-relative offsets, this was the limit.  (The
other 32K was used for global data)).

Ways to avoid this:
	o Cut down on the number of segments - your segments will be
	  larger, but you might be able to cut down on the number of
	  jump table entries.  This is pretty ugly.
	o If you're not using UPrinting, UGridView, UDialog, don't
	  initialize these units - this cuts down on the amount of
	  code you link in.  I ran into this problem and haven't
	  started implementing any printing yet, so I just took out
	  the UPrinting unit to give myself some time.
	o Compile and link with NoDebug Sym - this will shrink the
	  code size and allow you to keep writing and debugging code
	  as long as you don't need MacApps debugging gear.  This
	  hurts a bit.
	o Wait for MPW 3.2's 32-Bit-Everything, which will remove this
	  limitation.  If you Have the pre-release version of MPW 3.2
	  on ETO#2, it has this ability, although the release notes
	  warn that there are still bugs.
	o The MPW 3.2 linker has a -wrap option which will allow you
	  to use some of your global data space for additional jump
	  table entries.  However, if you're using MacApp, chances are
	  that you already have too much global data to do this.


There's probably some other things you can do, related to how you
segment your code, but this is one of the most annoying 'features' of
the mac right now.  Luckily it is on its way out.

anders