Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teaching Compilers Backward

blog.sigplan.org

Post reply on HN
Print view View original

11–20 of 87 posts

Re: Teaching Compilers Backward

#11

Post by Jtsummers »

smasher164 wrote: post #3

Much to the chagrin of a lot of educators, I think this approach is the way to go. Too many compilers classes get bogged down in grammar classifications and parsing. Some argue that parsing is a microcosm of the rest of the compiler, since it requires one to transform a program from one representation to another. However, this message doesn't really come across when you're operating on highly unstructured input, and…

Yeah. I got really good at parsing to an AST and various semantic analysis steps. One course got too bogged down there and we never went further. Another got to the point of emitting machine code, but no optimizations. Only one, in grad school, actually went the whole way (prof could assume knowledge of parsing so that step was fast) with anything on optimizations.

Given that parsing is also a critical part of many CS theory courses (or parsing theory), it was somewhat redundant to have spent so much time on it again in the compilers class given the overall time constraint, and frustrating to start on it and run past the planned time repeatedly in courses.

Re: Teaching Compilers Backward

#13

Post by agnokapathetic »

This approach has the added benefit of teaching "mechanical sympathy". We're often told "Let the complier do the work" without really understanding what "work" the compiler is doing.

Learning concepts like branch prediction, out-of-order execution, pipelining, register planning, caches, memory management is far far more important than Lexing/Parsing/Intermediate Representations and SSA.

Re: Teaching Compilers Backward

#14

Post by JoelMcCracken »

JoelMcCracken wrote: post #9
smasher164 wrote: post #3

Much to the chagrin of a lot of educators, I think this approach is the way to go. Too many compilers classes get bogged down in grammar classifications and parsing. Some argue that parsing is a microcosm of the rest of the compiler, since it requires one to transform a program from one representation to another. However, this message doesn't really come across when you're operating on highly unstructured input, and…

This is what happened in my compilers class. We spent, like, the whole thing talking about grammars etc. Which is mind-numbingly boring (to me), and especially given a significant number of industry parsers are hand-rolled/recursive descent style, its not terribly useful information.

At the moment, some of us in the PGH FP group are working through https://www.cs.cmu.edu/~rwh/pfpl/, and so far I vastly prefer it. It is math heavy, which I like for various personal reasons which are irrelevant here, but it also skips parsing!

Re: Teaching Compilers Backward

#16

Post by Mathnerd314 »

toolslive wrote: post #12

The bottom up order is the right one. The classic paper: An Incremental Approach to Compiler Construction (Abdulaziz Ghuloum) https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

They link this paper in the bottom of the article as a different approach from the one they're using.

Re: Teaching Compilers Backward

#17

Post by waynesonfire »

smasher164 wrote: post #3

Much to the chagrin of a lot of educators, I think this approach is the way to go. Too many compilers classes get bogged down in grammar classifications and parsing. Some argue that parsing is a microcosm of the rest of the compiler, since it requires one to transform a program from one representation to another. However, this message doesn't really come across when you're operating on highly unstructured input, and…

And, it seems to be is a really understood problem that has efficient solutions.

Re: Teaching Compilers Backward

#19

Post by tom_mellior »

toolslive wrote: post #12

The bottom up order is the right one. The classic paper: An Incremental Approach to Compiler Construction (Abdulaziz Ghuloum) https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...

That's not really the same approach. It's not "backward", it's more "sideways": It starts with an end-to-end compiler for a tiny language, then builds out that end-to-end compiler incrementally. The featured article describes an approach where no such end-to-end compiler is available from the beginning. It's only end-to-end after the final exercise.

Re: Teaching Compilers Backward

#20

Post by [deleted] »

agnokapathetic wrote: post #13

This approach has the added benefit of teaching "mechanical sympathy". We're often told "Let the complier do the work" without really understanding what "work" the compiler is doing. Learning concepts like branch prediction, out-of-order execution, pipelining, register planning, caches, memory management is far far more important than Lexing/Parsing/Intermediate Representations and SSA.

[deleted]
Post reply on HN