Path: utzoo!attcan!uunet!husc6!mailrus!tut.cis.ohio-state.edu!accelerator.eng.ohio-state.edu!raksha.eng.ohio-state.edu!rob
From: rob@raksha.eng.ohio-state.edu (Rob Carriere)
Newsgroups: comp.lang.c
Subject: Re: Numerical Recipes is non-portable code
Message-ID: <579@accelerator.eng.ohio-state.edu>
Date: 8 Sep 88 03:38:40 GMT
References: <564@accelerator.eng.ohio-state.edu> <7142@haddock.ima.isc.com>
Sender: news@accelerator.eng.ohio-state.edu
Reply-To: rob@raksha.eng.ohio-state.edu (Rob Carriere)
Organization: Ohio State Univ, College of Engineering
Lines: 23

In article <7142@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) 
writes:
>rob@kaa.eng.ohio-state.edu (Rob Carriere) writes:
>>marv@ism780.UUCP (Marvin Rubenstein) writes:
>>>[In a hypothetical extended C, with arrays x[5:49] and y[0:44], and an
>>>integer variable i, the accesses `x[i]' and `y[i-5]' should generate the
>>>same code on a reasonable compiler.]
>>
>> [ disagree ]
>If the architecture in question is "normal", then the compiler *is* free to do
>that optimization.  If the hardware will fault on the mere mention of an
>illegal pointer, then it can't optimize it -- but how do you think it's going
>to implement z=x[i], then?  They'll still generate the same code, but in this
>case it'll be equally bad rather than equally good.

Actually, if the system has memory to burn, the compiler might
allocate the 5 extra int's (probably only doing so for small lower
bounds, but those do make up almost all the cases anyway).  This is
similar to the fix to the Numerical Recipes vector() routine that I
posted a while ago.

Rob Carriere
"There's nothing quite like a broken architecture"