Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!spdcc!iecc!compilers-sender From: carter@cs.wisc.edu (Gregory Carter) Newsgroups: comp.compilers Subject: Re: the Evil Effects of Inlining Keywords: optimize, design Message-ID: <1991May5.025004.11897@daffy.cs.wisc.edu> Date: 5 May 91 02:50:04 GMT References: <1991May1.035622.25021@daffy.cs.wisc.edu> <1991May2.180508.17100@rice.edu> Sender: compilers-sender@iecc.cambridge.ma.us Reply-To: carter@cs.wisc.edu (Gregory Carter) Organization: U of Wisconsin CS Dept Lines: 56 Approved: compilers@iecc.cambridge.ma.us I suppose I should have outlined the process of combining procedural and inlined code replacement, so here it goes. What I initially wanted was for the source code to remain UNCHANGED. All transformations would be done without actually modifiying the source, only at the code generation stage. Therefore, the original source text, would remain the same, no extended compile times, no debugging problems. Only at the code generation stages would the inline effects be seen. On another note, some of you have mentioned that recursion would die this way, and since I have never been a big fan of recursion, and avoid it where possible, and very seldom do we think recursively (BE HONEST NOW) I thought this option would be common enough to actually be feasable. (Yes, recursion has its place, yes its useful, but it's a specialty item!) However, I would think there would be some money out there for you hot shots to design a paradigm which converts between recursive code and iterative code styles..AUTOMATICALLY. :) (Bring on the JOLT COLA) :) (Maybe some weekend when I have time, or when I find a competent CS536 prof) :) I was amazed to find that most of you skipped over the implications of inlining code blocks....JMP's(GOTO's)!!! (Isn't that a NO NO? Or is it?) I personally love GOTO's, which is part of the reason for my reason to trash the stack model (On the machine level, on the abstract level its very useful) (Please note above, I don't condone goto's. Although, they sure are QUICK) By the time you fix your stack frame, you're already executing your work code inline that is. Now for a radical idea. Hardware with global code support, instead of wasting that extra silicon real estate for a stack frame register? Any comments? Everyone secretly knows anyway that goto's are better, nicer and more efficient programming context for designing loops of all kinds anyway. (Of course, I will contend that too much of a good thing is bad..or is it?) :) Gregory (Have fun with that last one, and remember BE HONEST). [To each his own, I suppose. I find that the most natural way to express a nontrivial routine is more often than not recursive. Converting recursive programs to non-recursive mechanically is not hard. It must be, since no computer I know up supports recursion in hardware -- they all implement recursion with arrays of activation records. Also, the arguments about gotoless programming usually refer to programs written by humans, not programs written by machine, though on a deeply pipelined RISC, any sort of branch tends to be expensive. -John] -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.