webber@aramis.rutgers.edu (Bob Webber) (07/04/88)
In article <12298@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
< In article <395@proxftl.UUCP< bill@proxftl.UUCP (T. William Wells) answers
< Bob Webber with:
< [tail-recursive strlen deleted]
< <... Merely asserting that "any decent compiler would..." is not relevant.
< <This just asserts that YOU think that a compiler that does not deal with
< <tail recursion is not decent. In the real world, most compilers do NOT
< <deal with tail recursion, it not often being very useful to do this for
< <C programs.
<
< Actually, there are (only) two reasons `real world' C compilers do nothing
< about tail recursion: Hysterical Raisins, and debugging.
I agree that your Hysterical Raisins were Hysterical. However, re debugging:
< Debugging programs in which tail recursion has been optimised away is
< often a confusing experience. Combined with the Raisins, this may
< make enough of an argument to keep compiler writers from doing more work.
Well, personally I find the notion of automatically optimizing C code to
be shocking. I mean, like next thing you know people will be optimizing
assembler (cf. comp.arch). However, given that such folly is rampant in
the market place (probably due to the abandonment of the pure pdp-11/45
instruction set, heavy sigh -- I mean like with 80386s coming out our
ears and 65816s threatening to go 32 bit real soon now, would it have
been that hard to do 32bit version of pdp-11/45?) -- anyway, given that
optimizing C compilers are quite a thing of the present on commercial
unix boxes (e.g., Pyramids and Suns), is this one more optimization all
that much trouble? DBX aborts the opimizer anyway, so how does it impact
debugging? [I assume you saw that gcc does do tail recursion elimination
although not the analysis necessary to recognize the basic tail recursion
in the naive recursive strlen.]
--- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)