Poking holes into bytecode with peephole optimisations

26 pointsposted 23 days ago
by ibobev

8 Comments

lkey

20 days ago

The article is fine, except for the example, and I suppose by extension, the grammar of the lang itself.

The example: 2+3*4-1 should resolve to either LR: 19 RL: -7 PEMDAS: 13

and never this: 15

Who would expect a language where add/sub is more tightly binding than mul? Its feels akin to starting your indexes at 2, it's not illegal, if you remember everything works, but its a true foot gun in a scripting lang.

xnacly

19 days ago

Im sorry i forgot to highlight the braces around (2+3)*(4-1);

Either way the parser isnt implemented yet and all ast examples for the compiler are hardcoded

masklinn

20 days ago

Wouldn’t RL be 11? 2+(3(4-1)) = 2+(33) = 2+9

lkey

20 days ago

Depends on how you interpret (4-1) in your rl lang, 3 or -3.

elphard

20 days ago

I like that you are treating peephole as a strict fallback after IR optimizations, with a tiny window and single pass. In a lot of compilers this stage turns into a junk drawer of pattern matches that quietly grow until no one remembers why half of them exist.

The opt_trace! hook is the underrated bit here. Once you start rewriting instruction sequences, knowing which patterns fire and how often on real programs is usually more valuable than another synthetic benchmark. Keeping it behind -O1 is a nice way to make sure you only pay for that complexity when users actually opt in.

fweimer

19 days ago

Does it make sense to implement constant folding using peepholes for an ISA like this (with plenty of registers and limited scope for immediate operands)?

I would expect the constant loads to float away from their use sites, so that more instructions can use them. For example, 0 or 1 might be loaded at the start of the function.