HN Theater @HNTheaterMonth

⬐ WalterBright

"Unfortunately, there was a time when compiler writers considered it important to get most programs right but not necessarily all programs. When the programmer used some legal features in unusual ways, the compiler might implement an incorrect version of the program. This gave optimizing compilers a bad name."

I was the first to develop an optimizing C compiler for DOS (using data flow analysis). It was released as Datalight Optimum-C.

One of the programming magazines at the time decided to do a compiler roundup and prepared a number of benchmark programs. Optimum-C did incredibly well on them. The article writer did some investigating and concluded that Optimum-C cheated by deleting the benchmark code. We received a disastrous review.

The problem, though, was the benchmarks would do things like:

    a = b + c;
    a = b + c;
    ...

and the compiler correctly eliminated the dead assignments, and hence most of the benchmark.

The other compiler vendors weren't fooled, however, and quickly added data flow analysis to their compilers, and the benchmark code was forced to change.

But that review hurt us badly. The author at least could have contacted us over the unusual results.

⬐ vmh1928

This is a good paper on the theory and history of compiler development. (from 1997)

https://keybase.theophile.me/info/morgan-optimizing-compiler...

⬐ WalterBright

"Unfortunately, there was a time when compiler writers considered it important to get most programs right but not necessarily all programs. When the programmer used some legal features in unusual ways, the compiler might implement an incorrect version of the program. This gave optimizing compilers a bad name."

The first optimizing C compiler for DOS (using data flow analysis) was released as Datalight Optimum-C in the 1980s.

One of the programming magazines at the time decided to do a compiler roundup and prepared a number of benchmark programs. Optimum-C did incredibly well on them. The article writer did some investigating and concluded that Optimum-C cheated by deleting the benchmark code. We received a disastrous review.

The problem, though, was the benchmarks would do things like:

    a = b + c;
    a = b + c;
    ...

and the compiler correctly eliminated the dead assignments, and hence most of the benchmark. The other compiler vendors weren't fooled, however, and quickly added data flow analysis to their compilers, and the benchmark code was forced to change.

But that review hurt us badly. The author at least could have contacted us over the unusual results.

⬐ lowbloodsugar

From the main author of LLVM, in case you don't recognize the name.

It is a nice overview, and then 25 minutes of advertising RISC-V, which his company, SiFive, is focused on.

⬐ redis_mlc

Stop being childish.

As you approach the state-of-the-art, all of the practitioners will have commercial interests, and that includes promotion and conflicts-of-interest.

That's the price of listening to world-class experts.

⬐ earleybird

More on the topic of hw/sw co-design from another fellow you might recognize: https://www.youtube.com/watch?v=nY07zWzhyn4

⬐ mwattsun

The other talk Dr. Chris Lattner recommends watching is this one, and is very interesting

David Patterson - A New Golden Age for Computer Architecture: History, Challenges and Opportunities

https://www.youtube.com/watch?v=kFT54hO1X8M

I didn't realize IBM would have went with the Motorola 68000 for the IBM personal computer if Motorola had been ready. That would have been awesome for me because I could have applied my Mac 68000 asm skills to the much larger IBM PC market.

⬐ mwattsun

Towards the end he talks about some general rules he has found for a happy life.

    What Worked Well for Me [1] by David Patterson

    • Maximize Personal Happiness vs. Personal Wealth 
    • Family First! 
    • Passion & Courage 
        - Swing for the fences vs. Bunt for singles 
    • Friends may come and go, but enemies accumulate
    • Winning as Team vs. Winning as Individual 
        - "No losers on a winning team, no winners on a losing team" 
    • Seek Out Honest Feedback & Learn From It 
        - Guaranteed Danger Sign: "I'm smartest person in the room"
    • One (Big) Thing at a Time 
        - "It's not how many projects you start Its how many you finish"

    • Natural Born Optimist 
    
    [1] Full video: see "Closing Remarks", www2.eecs.berkeley.edu/patterson2016

I contribute to CIRCT, so I feel like I should chime in here. I personally hope that it can provide exactly the kind of unifying IRs we are all hoping for in the open-source community. The fact that the tools are implemented in C++ may be a win for some, but I think the CIRCT project is compelling for much deeper reasons. The README states the ambition clearly:

> By working together, we hope that we can build a new center of gravity to draw contributions from the small (but enthusiastic!) community of people who work on open hardware tooling.

There are weekly community meetings that are open to the public, and we have guest speakers from all sorts of interesting projects in the open-source community. Many of those are leading to collaborations and contributions to CIRCT.

There hasn't been much (any?) discussion of CIRCT on HN, but rather than present the reasons I think it's so great here, I'll point to a talk[1] I gave earlier this year and a much better talk[2] Chris Lattner gave shortly thereafter, both of which lead up to the "Why CIRCT?" question in the second half.

Looking back at that SymbiFlow thread, I see familiar faces that are now actively contributing to CIRCT. There are mentions of many different hardware IRs in some of the posts, but at least three have first-class support in CIRCT today: FIRRTL[3], LLHD[4], and Calyx[5]. This is all very recent and experimental, but I would say the results are already promising.

[1] https://slideslive.com/38955645/applying-circuit-ir-compiler...

[2] https://www.youtube.com/watch?v=4HgShra-KnY

[3] https://circt.llvm.org/docs/Dialects/FIRRTL/

[4] https://circt.llvm.org/docs/Dialects/LLHD/

[5] https://circt.llvm.org/docs/Dialects/Calyx/

You might like this talk that describes parts of the compiler ecosystem that are lacking standardization for accelerators

https://www.youtube.com/watch?v=4HgShra-KnY

⬐ self

Presentation slides: https://docs.google.com/presentation/d/1ZMtzT6nmfvNOlIaHRzda...

Related - John Hennessy and David Patterson 2017 ACM A.M. Turing Award Lecture: https://www.youtube.com/watch?v=3LVeEjsn8Ts

⬐ teleforce

Excellent talk, this could be seminal in the years to come.

It is really aptly that the Turing Award for this year is awarded to the pioneers of modern compiler design [1].

It will be interesting to see how modern compiler techniques namely Single Static Assignment (SSA) and Polyhedral/Polytope can enable heteregenous high level synthesis (HLS) and multi-level compilations for both hardware design and programming [2].

[1]https://amturing.acm.org/

[2]https://arxiv.org/abs/2103.15103