Re: the Evil Effects of Inlining

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]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.