4 ms·
The author seems to be misinformed about the relative value of compiler front-end versus compiler back-end. Front-end is not where the challenges are in any pr
by dbcurtis 7y ago
The author seems to be misinformed about the relative value of compiler front-end versus compiler back-end.
Front-end is not where the challenges are in any production compiler. The hard work is in the optimizer. Lexical and syntactic analysis are homework problems for sophomores. That is not where any of the value in a production-worthy compiler lives, no more than the value of your C++ code being found in the semi-colons at the end of the statements.
- sitkack 7y agoWrt to the outline for someone wanting to self study in the area, what are you thoughts?
- dbcurtis 7y agoBy "this area", are you referring to front-end, or back-end? I am going to guess back-end, because there are a lot of self-study tutorials for front-end that you probably have already found. Unfortunately, I am not an expert in back-end, although at one point I did manage a group that was involved in compiler validation -- but I was pointy-haired, it was my team that knew the innards of the compiler. Advanced texts in compiler construction are going to get into data flow analysis and liveness testing, and talk about basics of code motion. These are all elementary topics and barely touch on the state-of-the-art, but are foundational. Also, get good at reading the assembly language for the machine of your choice and look at the .S files. Sorry I can't be of more help, but maybe I gave you some search terms.
- sitkack 7y agoI was speaking generally in terms of self learning in compilers. Your criticism was that the article focused too heavily on the front end and that the magic or the needed focus is on back end issues (scheduling, selection). I think there are a couple things in play here. Folks working with text, semi-structured data, synthesizing from disparate sources, etc will be front end heavy. Tokenization, lexing, is important outside of more than compilers, like loading binary formats from network or disk into memory. For backend work, being able to extend or modify existing backends is important for languages targeting different runtimes (Spark, Beam, Impala). This can be in targeting new architectures or for predicate pushdown into data processing pipelines. Lots of different applications to use those skills. Compilers and Database systems are an incredible microcosm of many areas of CS. Areas of self study I think are nice are MAL - Make a Lisp https://github.com/kanaka/mal https://github.com/kanaka/mal Nand2Tetris, project 11 https://www.nand2tetris.org/project11 https://www.nand2tetris.org/project11 (one should start from zero and make your way here, it is journey not a destination) An educational software system of a tiny self-compiling C compiler, a tiny self-executing RISC-V emulator, and a tiny self-hosting RISC-V hypervisor. http://selfie.cs.uni-salzburg.at http://selfie.cs.uni-salzburg.at LLVM is a huge system, libFirm is a much smaller, simpler system that includes a c front end. From their site > libFirm is a C library that provides a graph-based intermediate representation, optimizations, and assembly code generation suitable for use in compilers. https://pp.ipd.kit.edu/firm/ https://pp.ipd.kit.edu/firm/
- Jasper_ 7y agoThe large focus on parsing and grammar theory in traditional CS education is part of this, despite it's extremely limited usefulness in any production compiler. There's plenty of interesting work to do in the frontend too but a lot of it is past the parsing stage.
- saagarjha 7y agoThe author worked on the Swift compiler frontend.
- DeathArrow 7y agoJudging by the author's advices, he's referring to a toy compiler, not a production ready compiler. Language architecture and writing a compiler are very difficult tasks if the intent is to come up with a production ready compiler. I suppose that if you want to do a toy compiler for a very small and limited language, there are simpler ways than getting into lexers and parsers. You can str replace with assembly language or C instructions and function and compile to C or assembler.
- danielscrubs 7y ago"Front-end is not where the challenges are in any production compiler." It's an extremely complex problem in itself, because most frontends strive for supporting autocompletion of broken/half-finished code with good performance and type hints. How many are really happy with their IDE's? I remember Borland Pascal IDE and Visual Studio 6 being shining examples and after that... I don't really know what happened. Tried a Scala project with VSCode, takes around a minute for it to pick up my variable changes and 100% CPU, even worse with SwiftUI and XCode. And the computers back then had what? 600mhz? I'd say, move some c++ graybeards to the frontend team to fix this mess.