4 ms·
Compilers is one of these field that didn't evolve much for ~30 years. I used to teach a course at Perugia University back in 2004-2006, and the material I coul
by simonebrunozzi 3y ago
Compilers is one of these field that didn't evolve much for ~30 years. I used to teach a course at Perugia University back in 2004-2006, and the material I could use was easily 15-20-25 years old, no sweat.
Things seem to have changed recently.
- grumpyprole 3y agoProbably because most programming languages haven't changed, imperative, loops, pervasive side-effects etc. Writing a compiler for a pure functional language would certainly need new material.
- dunefox 3y ago> Writing a compiler for a pure functional language would certainly need new material. I mean, Haskell is also over 30 years old at this point.
- grumpyprole 3y agoYes, but it's changed a lot in 30 years.
- pjmlp 3y agoOn top of sibbling comment, Simon Peyton Jones seminal paper is from 1987.
- grumpyprole 3y agoHe has spent the last 30 years since publishing more papers on compiling functional languages.
- pjmlp 3y agoMostly related to adding new features to Haskell and GHC, not on compiling functional languages in general. Now functional logic languages like Verse, that is definitely new material.
- grumpyprole 3y agoThat's selling him very short. I would say most of his papers are applicable to functional programming in general and not just Haskell.
- pjmlp 3y agoOnly for those that understand functional programming as whatever Haskell does.
- snnn 3y agoNo, I think it is because most problems are too hard to solve. Think a simplified case: build a compiler for evaluating arithmetic expressions like "a*3+b" and make the generated code as efficient as possible. It is an NP-hard problem!
- pfdietz 3y agoThere's been a substantial change in compiler testing since then, with high volume randomized testing coming into vogue.
- looofooo0 3y agoRecent papers with llm Fuzzing appearing e.g. fuzz4all
- wslh 3y agoWe are working on projects related with cybersecurity and compilers. A reference we look at is [1] and [2]. I think we can publish the results in the coming months. [1] https://github.com/rohanpadhye/jqf/wiki/Fuzzing-a-Compiler https://github.com/rohanpadhye/jqf/wiki/Fuzzing-a-Compiler [2] https://news.ycombinator.com/item?id=36373410 https://news.ycombinator.com/item?id=36373410
- sjrd 3y agoI disagree. The landscape has significantly evolved into incremental compilation techniques in the past decade. While theoretical developments are mostly confined into parsers, practical implementations do it across the entire pipeline, all the way to whole-program optimizations and code generation.
- mr_foo 3y agoI'm not well versed in compiler design or implementation. But it seems to me that the target of compilers (machine code, assembly, etc.) has changed dramatically over time. The number of instructions and options on each successive processor generation seems to offer new optimizations or combinations for compilers.
- deleted 3y ago[deleted]
- jcranmer 3y agoThat's just not true. Just going by the new stuff that you could have taught back in 2004-2006 that you likely didn't, there's SSA construction, SLP vectorization, automatic peephole superoptimization, and that's just things I could name off the top of my head (and were papers for my qualifying exam :-P). What hasn't changed is the compiler textbooks, which tend to have way too heavy a focus on how to build a parser generator and almost nothing on how you actually architect a compiler, let alone designing modern computer architecture. But this is a gripe which has been around for decades.
- GrumpySloth 3y agoNitpick: SSA is late 80s, early 90s tech.
- jcranmer 3y agoI'm dating SSA from the "Efficiently computing static single assignment form and the control dependence graph" paper, which came out in October 1991; my understanding is that SSA wasn't heavily used before this technique came out.
- deleted 3y ago[deleted]