Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!helps!bigtex!james From: james@bigtex.cactus.org (James Van Artsdalen) Newsgroups: comp.unix.sysv386 Subject: Re: alloca for V.4? Message-ID: <48846@bigtex.cactus.org> Date: 21 Oct 90 17:58:23 GMT References: <2064@sixhub.UUCP> <1457@gandalf.littlei.UUCP> Reply-To: james@bigtex.cactus.org (James Van Artsdalen) Organization: Institute of Applied Cosmology, Austin TX Lines: 38 In <1457@gandalf.littlei.UUCP>, vrs@lint.hf.intel.com (Vincent R. Slyngstad) wrote: | Has anyone written an alloca for V.4? > The compiler in V.4 is so optimizing that the output code doesn't > resemble the input source all that much. In particular, the compiler > plays fast and loose with stack frames, especially when inlining. > This isn't really a V.4 issue, since a sufficiently optimizing > compiler could/would have done the same thing on V.3. I don't think the v.4 compiler does that much better than the v.3 compiler. I'm not sure it's any better. It tries real hard to be ANSI, but doesn't seem quite there yet. The preprocessor makes a hash of its input (tokenizes everything, macros or not). The include files make curious assumptions about __STDC__. It is *not* necessarily the case that an optimizing compiler will fail to maintain stack frames. Stack frames are not expensive unless you make them that way, and in any case, function inlining can take care of truly trivial functions. I happen to like being able to debug programs - trading away debug capability for speed is a bad idea. gcc does a better job than the v.3 or v.4 compilers, yet it maintains stack frames. gcc can also be used on "old-style" sources, whereas the v.4 compiler cannot (yet - I assume this will change). > On the upside, a lot of source compatibility features were *added*. > You'll like that the next time you are porting source from a BSD based > environment. Stay away expecially from undocumented features (like > alloca). alloca(3c) is well documented and widely used. The "portable" alternatives are very poor. It would seem a major compatibility hole, so much so that it ought to be fixed. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Dell Computer Co 9505 Arboretum Blvd Austin TX 78759 512-338-8789