Hi Neil, How did you get the bytecodes you looked at? I suspect you might be printing the bytecode too early (i.e. not the final form). I suspect this because ...
== SLIDE 0 =I noticed some of these, I take it they are a noop? If so, lets peephole them away! Probably one line of code...
... this is already implemented, in Bytecode/Peep.hs peepIns (SLIDE 0:is) = peepIns is Along with others like POP 0, SLIDE n;SLIDE m, SLIDE n;RETURN, EVAL;EVAL.
== JUMP_FALSE -> JUMP_ZERO =If we moved from JUMP_FALSE to JUMP_ZERO (which i take it is the same semantics anyway!) then this could often be used for case statements on two constructors (say lists, for example). Also case on a bool is expanded to a case, if we had JUMP_ZERO this could be collapsed back as a more general transformation. Less code, faster code, happier code.
You could, on the downside it might complicate Hat G-Machine tracing somewhat though ... (because now you need to issue a case even though the bytecode is for an if etc.)
== EVAL; JUMP; RETURN =I noticed a few things that EVAL, then JUMP, then RETURN - of course you could collapse the EVAL to EVAL_RETURN and throw away the jump. Less code, more speed, everyone is happy :)
Again I suspect you're printing the code out too early because I believe it should do this already. The compiler traces the possible paths through the program and if it must end in a return then it replaces the jump with a RETURN instruction instead of a jump. i.e. << BLAH >> << BLAH >> JUMP end becomes RETURN << BLAH >> << BLAH >> end: RETURN RETURN And EVAL ; RETURN is removed by the peepholer peepIns (EVAL:RETURN:is) = peepIns (RETURN_EVAL:is) (infact this is the only place that RETURN_EVAL can be introduced into the code).
== branch factorisation =I noticed a few cases where two branches both jump to the same place, and execute the same code, but the code before the jump's are the same. These could be factorised into the after the jump bit - less code, same speed, there
Yes both this and the related optimisation of common code merging (i.e. if there are two seperate blocks of code that are actually identical) didn't seem to be common enough to merit the effort. Of course it would be possible but I figured it was probably only one or two bytes in one or two functions. Hope that answers your questions :-) Tom