Pete's Log: Log Entry 262

Entry #262, (Coding, Hacking, & CS stuff)
(posted when I was 21 years old.)
Alright, I've finally gotten myself into code generation for ice9. It's rather fun, and I've several ideas for cool things to do. I've already added three new command line options to the compiler:

-u, for Unoptimize, which turns off optimizations
-r, for Rolled, turns off loop unrolling (but leaves other optimizations)
-l, for Loop, allows specification of how big loops can be before they don't get unrolled

My loop unrolling approach is going to be very simplistic, and I think it will only apply to fa (for all/each) loops. Basically, if the upper and lowed bounds of a fa loop are constants, and are within a certain "distance" of each other, I'll really simplistically unroll the loop. I think this could actually have a decent performance boost, especially for tight loops, because tm is simplistic enough to make loops kinda expensive.

I also intend to come up with a good register allocation scheme, better than the accumulator scheme that Dr. Freeh suggests we use. tm has 8 registers, of which one is the PC, and I'm using two more for frame and stack, so I have 5 registers. It seems kinda wasteful to me to use one of those as an accumulator and the rest just as temporaries. I wish I could find a good resource on register allocation, but for now I'll just wing it, since it really doesn't need to be optimal at all.

Dead code elimination is also a goal. This should be easy for simple cases. For example, during semantic analysis, I can keep track of which procedures get called and which don't, and simply not generate code for those that don't. That won't catch something like having proc a calling proc b, but nothing calling a, since that'll eliminate a, but not b, unless I do the semantic pass multiple times, which seems wasteful. At least I'm not writing a just-in-time compiler or something.

Dr. Freeh told us we don't have to worry about nested procedures:

proc a(b: int)
  proc b(c: int)
    ...
  end
  ...
end
because that makes the frames a good deal more complex, but I think I might give that a try later...