Brian Callahan writes on compilers, C and Ada toolchains, OpenBSD, and building programs that create programs.
HN commenters cite his compiler-writing series and benchmark posts, and link his articles on parsing and tokenizing without an AST.
You might be underestimating the intricacy of the CPU models LLVM uses.
If you want to see them in action, the same data drives llvm-mca[1], which given a loop body can tell you the throughput, latency, and microarchitectural bottlenecks (decoding, ports, dependencies, store forwarding, etc.)—if not always precisely, then still as well on average as, say, x86’s IACA, the tool written at Intel by people who presumably knew how those CPUs work, unlike LLVM contributors and the rest of us who can only guess and measure. This separately for Haswell, Sandy Bridge, Skylake, etc.; not “x86”.
Now, is this the best model you can get? Not exactly[2], but it’s close enough to not matter. Do we often need machine code optimized that finely? Perhaps not[3], and if you’re using generic distro binaries, you’re not getting it, either. (Unlike Facebook, Google, etc., who know precisely what their servers have inside, and who fund or contribute sizable portions of this optimization work.)
With that in mind you can shave at least a factor of ten off LLVM’s considerable bulk at the cost of 20—30% of performance[4,5]. But if you do want those as well, it seems that the complexity of LLVM is a fair price, or has the right order of magnitude at least.
(Frontend not included, C++ frontend required to bootstrap sold separately, at a similar markup compared to a C-only frontend with somewhat worse ergonomics.)
[1] https://llvm.org/docs/CommandGuide/llvm-mca.html
[2] https://www.uops.info/
[3]…
You got it! By approximate category and in no particular order:
## MISCELLANEOUS
- [Low Tech Magazine](https://solar.lowtechmagazine.com), a solar-powered website showcasing the amazing low-tech things you can do with a little ingenuity,
- [Stephen Wolfram's Blog](https://writings.stephenwolfram.com) on math, compsci, and everything else,
- [Cool Macrophotography](https://www.barrywebbimages.co.uk/Images/Macro/Slime-Moulds-Myxomycetes) for amazing pictures of tiny things (WARNING: Time Sink!),
## COMPUTER SCIENCE
- [While-True-Do](https://blog.while-true-do.io) has lots of stuff on Linux administration and self-hosting,
- [Backend Banter](https://www.backendbanter.fm) for a great podcast on backend development,
- [Two Wrongs](https://two-wrongs.com) for statistics and functional programming,
- [Math ∩ Programming](https://www.jeremykun.com/) where math and programming intersect! Written by a Googler...
- [Paul Bourke's site](https://paulbourke.net/) where you can get happily lost exploring old pages on every topic CS touches,
- [Jason Punyon's blog](https://jasonpunyon.com) for some fun algorithms and things,
- [Yossi Kreinin's blog](https://yosefk.com/blog) for C, Python, and plenty of non-technical topics,
- [Adrian Sampson's academic blog](https://www.cs.cornell.edu/~asampson/blog) for an academic's perspective,
- [Cool polyhedra viewer project](https://georgehart.com/virtual-polyhedra/vp.html) if you like geometry,
- [Another academic blog on…
Crafting Interpreters [0] just came out in print and was widely discussed here [1], there's a Lang Jam [2] event happening this weekend which also spawned a useful HN discussion [3], so I just think a lot of readers here are interested in simple and fun language development tutorials and inspiration. But it is curious, part 2 of Brian Callahan's series [4] failed to get any traction here, maybe people aren't that into lexing?
[0] https://craftinginterpreters.com/
[1] https://news.ycombinator.com/item?id=27997167
[2] https://github.com/langjam/langjam
[3] https://news.ycombinator.com/item?id=28021161
[4] https://briancallahan.net/blog/20210815.html
EDIT:
Paste this hacky snippet into your browser's console to save all of the links into your clipboard:
(() =>
{
let result = [...document.querySelectorAll('td a')]
.map((link) =>
link &&
!link.href.includes('ycombinator') &&
!link.href.includes('javascript:void')
? link.href
: ''
)
.filter(Boolean);
result = [...new Set(result)];
result.sort();
copy(result.join('\n\n'));
})();
Just to help, here's a compiled-list of all of the links shared here so…
I don’t think there will be an AST. https://briancallahan.net/blog/20210814.html: “We will be writing a single-pass compiler for a simple language and immediately output our final output code as soon as our compiler has enough information to do so”
That “as soon as” implies code will be generated before the entire program has been parsed.
Also, for me single-pass implies “no AST”, as you would need at least one pass to construct one, and iterating over an AST counts as another pass for me.
MS-DOS 1.0 used CP/M-80 System Calls to make it easier to port programs from CP/M to DOS. https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/section5/
https://groups.google.com/g/comp.os.cpm/c/hj2M4TIRRKE
https://www.landley.net/history/mirror/ms/InsideDos.htm
https://briancallahan.net/blog/20210606.html