Next steps for Inform 6 compiler

Authoring Inform 6
102

You probably would need to recognize a pattern and optimize on individual patterns. Is it worth it? I don’t know?

103

The compiler doesn’t have a good way to recognize patterns across more than one basic operation.

However, this specific case is generated within one operation. The code looks like

assemblez_2_to(get_prop_addr_zc, AO,
    ET[ET[below].right].value, temp_var1);
if (!void_flag) write_result_z(Result, temp_var1);

So we could add another case saying, roughly, if Result is stack_pointer and (!void_flag) then do this instead:

assemblez_2_to(get_prop_addr_zc, AO,
    ET[ET[below].right].value, stack_pointer);

This is conceptually simple. The only annoying thing is that this pattern appears in about twenty places in the compiler code (representing various operations). So the full fix is fairly messy, and it’s probably worth refactoring a little to keep things tidier.

8 Likes
104

I have somewhat revived this thread (see Code generation optimizations · Issue #87 · DavidKinder/Inform6 · GitHub) and implemented optimizations for a couple of things:

  • @get_prop and @get_prop_addr now skip intermediate storage of result in temp-variable when target result is the stack.
  • x=x+1 is compiled as i++ (@add x 1 -> x to @inc x) and similiar.

These changes saves 460 bytes on Curses and 284 bytes on Advent. I have tested with a playthrough of Curses without issues but more testing is obviously needed (anybody interested?).

I’m also happy if there are more suggestions for improvement (other than the ones already suggested in this thread or the ones on GitHub). I’m trying to cram multiple improvements together as so to minimize the testing needed (one testing phase for all, instead of testing each individual change).

4 Likes