[Yhc] Yhc bytecode thoughts

[shackell at cs.york.ac.uk]

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