alloca for V.4?

[James Van Artsdalen]

In <1457 at gandalf.littlei.UUCP>, vrs at 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 at bigtex.cactus.org   "Live Free or Die"
Dell Computer Co    9505 Arboretum Blvd Austin TX 78759         512-338-8789