On Fri, 2006-07-28 at 23:34 +0900, Miles Bader wrote: > Jeffrey Law <law@xxxxxxxxxx> writes: > > Whomever wrote it doesn't know what they're talking about, at least > > not in regards to efficiency of storage access in general purpose > > C compilers. > > Indeed. > > I guess there _are_ machines/environments where static allocation is > better, because I've run across programs where they quite annoyingly > declare just about every (semantically) "local" variable as static. Certainly on some specialized processors accessing memory can be fast. Consider a processor where registers are really just aliases for memory locations or things like high speed zero page memory access. I've used such processors a few times in my life, but I try real hard to forget them ;-) > In particular, many of the EEMBC benchmarks do this (or at least did at > one time), for apparently no good reason at all. I guess the original > author had one of these funny machines. Several of the EEMBC benchmarks are centered around applications that at one time or another were primarily implemented on top of highly specialized processors, particularly DSPs. > As this screws up gcc's optimization big time, I actually wrote a gcc > patch at one time that detected such "artifically static" variables and > changed them into normal automatic variables (at the time I was > comparing EEMBC results for gcc versus Greenhill's compiler -- the > latter already dealt with such artifically static variables, though as I > recall, it did so in an unsafe manner). "promoting" statics to autos certainly can be done by the compiler if you're willing to do use & escape analysis. Nontrivial, but possible. jeff
