Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!rutgers!bellcore!faline!ulysses!sfmag!sfsup!shap From: shap@sfsup.UUCP (J.S.Shapiro) Newsgroups: comp.sys.mac Subject: Re: Mac Programming Query Message-ID: <2738@sfsup.UUCP> Date: 2 Feb 88 05:22:15 GMT References: <46100070@uxe.cso.uiuc.edu> Organization: AT&T-IS, Summit N.J. USA Lines: 39 Summary: Large Programs are possible In article <46100070@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: > > In the review of MPW C in the current issue of Byte, it is stated that > a Mac program can't have a "code segment" longer than 32K, nor more > than 32k of static data. Well, this is true and it isn't. The reason behind all of this is a limitation on the 68000 concerning indirect addressing. To get to any such things, the Mac compilers generate an addressing mode which amounts to (segment base) + offset, and on the 68000 you could only offset by 16bits * 4 bytes per word == 32k, consequently the limit. The addressing mode is called "Address Register Indirect with Displacement" Now before you panic, this is only a limit if you want to do relocatable code. It is possible to generate so-called "large model" code, and most of the current crop of C compilers do. Unfortunately, such code is not guaranteed to run under multifinder (read: probably wont) because it needs to be absolute addressed. Note also that on the m68020, the Address Register Indirect with Displacement addressing mode has been expanded to handle up to 32 bit displacements - the full addressing range. Unfortunately, when Apple defined the CODE resource they permitted only 16 bits for the offset entry. Like I said, the answer is "yes and no." In my opinion, it is time that Apple introduced a new code resource, COD2, that allowed the full 32 bit range. While this would not run on the non-68020 macs, the classes of problem for which people are buying Mac-II's demand it. It shouldn't be terribly hard to write a patch to the segment loader to handle this problem. Since you can have multiple code segments, there is no problem with that. My advice to you conerning static data is that you should put your static data in a resource and load it into a hand-allocated heap resource. Messy, but it will work. Jon