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.
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.
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.
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.
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
Wouldn’t RL be 11? 2+(3(4-1)) = 2+(33) = 2+9
Depends on how you interpret (4-1) in your rl lang, 3 or -3.
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.
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.
[flagged]
[flagged]