One-pass Compiler

Re:One-pass Compiler by klyrs on Saturday May 23, 2020 @10:33AM (#23283244)

> Interestingly, this restriction does not apply to goto labels, which you can use first and define later: The compiler can just emit the label as written into the assembly code and let the assembler worry about patching up the jump target.

A one-pass compiler can manage this by maintaining a mapping of undefined labels to a list of goto statements that refer to them. Once the definition is located, unwind the list and fill in the jump values. Types are trickier because the size is unknown.

[ Parent | on HN ]

Re:One-pass Compiler by tom_mellior on Saturday May 23, 2020 @10:43AM (#23283340)

There is no way to "fill in the jump values" if you have already emitted the goto to a place you can't modify later. Like the featured article does, emitting its code with printf. I agree that you could emit code to an intermediate buffer, fix it up later, and still call this (a slightly more relaxed version of) one-pass compilation.

[ Parent | on HN ]

Re:One-pass Compiler by klyrs on Saturday May 23, 2020 @11:07AM (#23283530)

Fair point... kinda feels like passing the buck, but not having that memory overhead is nice

[ Parent | on HN ]