Path: utzoo!yunexus!hydroesm!jtsv16!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!primerd!ENI!ENS!J.COOK From: J.COOK@ENS.Prime.COM Newsgroups: comp.sys.mac.programmer Subject: Re: Need large array on Think C. Message-ID: <1232500001@ENS.Prime.COM> Date: 29 May 90 14:16:00 GMT Article-I.D.: ENS.1232500001 References: <26645@<265986A9> Lines: 30 Nf-ID: #R:<265986A9:-2664500:ENS:1232500001:000:1517 Nf-From: ENS.Prime.COM!J.COOK May 29 14:16:00 1990 There has been some discussion of a note from stoms@castor.ncgia.ucsb.edu >> Sorry for this trival question, but I really need to get this >>done. When I declare an array ('char arr[100][300]'), the complier >>gives me an 'illegal array bounds' error. Is there any way I can >>increase this limit? I find it too bad that all solutions in C involve allocating the array at runtime and then referencing the variable through a pointer variable. The resulting loss of efficiency due to indirection is disappointing. It is particularly bad when you realize that compilers (both C and Pascal) tend to not perform cross-statement register tracking (I admit I am unsure about MPW). The effect is that the pointer to the array must be reloaded into a register for each statement that references the array, regardless of whether the pointer is already present in a register or not. This is a general problem. Compilers on the Mac lack optimization. Dataflow analysis? Flow analysis? Code migration? Constant subexpression optimization? Loop invarient removal? Cross-statement register tracking? Back-patching? Never seen them on the Mac. Compiler-writers cite lack of demand for it. Sigh. It would seem to me that good code optimization could noticeably improve the performance of many applications. Just by improving the code efficiency, you could gain much of the effect of some hardware accelerators for the price of a compilation. Jim Cook "Just my misinformation, not Prime's."