[Yhc] Re: Yhc bytecode thoughts

[Neil Mitchell]

> == 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...

Woops, I was doing -bcodecompile, I notice that peepholing is done
after that. I also notice that eval; jump; return is correctly
flattened. The other two points still apply I think, particularly
JUMP_FALSE.

It would be useful to have documentation somewhere on what each of the
debug flags does. I also can't find a debug flag that prints out the
bytecode pretty much as the compiler generates, which is unfortunate.
Also -bcodeflatten shows the flattened output, but doesn't include
non-conditional jumps, which makes figuring out what is going on
impossible.

Thanks

Neil

>
> == 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.
>
> == 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 :)
>
> == 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 are possibly more important things before
> worrying about this...
>
> Thanks
>
> Neil
>