[arthurbrown]

Russ Cox wrote a great comment[1] on HN about why using the Plan9 toolchain rather LLVM or even GCC was a competitive advantage for them in terms of speed to delivery, control, and iteration.

"Most importantly, it has been something we understand completely and is quite easy to adapt as needed. The standard ABIs and toolchains are for C, and the decisions made there may be completely inappropriate for languages with actual runtimes.

For example, no standard ABIs and toolchains supported segmented stacks; we had to build that, so it was going to be incompatible from day one. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two."

"... the custom toolchain is one of the key reasons we've accomplished so much in so little time. I think the author doesn't fully appreciate all the reasons that C tools don't work well for languages that do so much more than C. Most other managed languages are doing JIT compilation and don't go through standard linkers either."

[1] https://news.ycombinator.com/item?id=8817990

[pcwalton]

> For example, no standard ABIs and toolchains supported segmented stacks; we had to build that, so it was going to be incompatible from day one. If step one had been "learn the GCC or LLVM toolchains well enough to add segmented stacks", I'm not sure we'd have gotten to step two."

LLVM now supports both segmented stacks [1] and precise garbage collection with patchpoints [2].

Tweaking support for segmented stacks is quite easy—I added the support for it on x86 Mac. You simply adjust the prolog emission code in X86FrameLowering.cpp and likewise for the other targets.

[1]: http://llvm.org/docs/SegmentedStacks.html

[2]: http://llvm.org/docs/StackMaps.html http://llvm.org/docs/Statepoints.html

[sunnyps]

Yeah, the point is that it wasn't there at that time.