Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!ames!ig!bionet!agate!skippy!lippin From: lippin@skippy.berkeley.edu (The Apathist) Newsgroups: comp.sys.mac.programmer Subject: Re: THINK C Array Design Flaw Message-ID: <24093@agate.BERKELEY.EDU> Date: 6 May 89 02:20:19 GMT References: <664@loligo.cc.fsu.edu> Sender: usenet@agate.BERKELEY.EDU Reply-To: lippin@math.berkeley.edu Organization: Authorized Service, Incorporated Lines: 42 Recently pepke@gw.scri.fsu.edu (Eric Pepke) wrote: [...] ]In one of my programs I need to use an array of 32*32*32 short integers, ]which is 64K long. The segment loader problem doesn't bother me. I am ]perfectly happy allocating the memory, passing a pointer into a function, ]and declaring it as I want it in the function. So, I tried something like ] ]AddHist(theHist, r, g, b) ]short theHist[32][32][32]; ] ]which caused a compiler error, in spite of the fact that the function does ]not have to define the array at all. Looks like they blew that one. I'm surprised it hasn't come up before. ]short Access7(array, a, b) ]short array[7][7]; ]short a, b; ]{ ] register short result; ] result = array[a][b]; ]} [more code deleted] ]The techniques in both functions generalize to higher order and larger ]arrays. ACCESS4 does an arithmetic shift on a longword, so it can be ]expected to work when the array is larger than 32K. ACCESS7 only does a ]single word multiply, so it can be expected to fail on large arrays. It is ]also a *signed* multiply, which makes little sense. The code generated for Access7 looks correct to me. The key point is that the MULS.W instruction produces a long result. Since the code needs to multiply a, a *signed* word, by 14, MULS.W is the most straightforward way to get the right result. Problems with 32K will only arise if a>=32K (which it can't be) or if the row size>=32K, in which case I presume (or at least hope) different code is generated. --Tom Lippincott lippin@math.berkeley.edu "Foo, you are nothing but a charlatan!" --Adventure