9 ms·

Worth mentioning other alternative small backends: http://c9x.me/compile/ http://c9x.me/compile/

ddevault 6y ago
I use qbe, it's great. Here's a mostly feature-complete C11 compiler based on qbe: https://git.sr.ht/~mcf/cproc https://git.sr.ht/~mcf/cproc
- hawski 6y ago
  I see that cproc is under quite heavy development, but qbe had last commit at the end of November. Is it considered feature complete? I heard about it some months ago and was quite interested in QBE, but it did not enjoy high tempo of changes. It may be considered advantage, I know too little to judge.
  - ddevault 6y ago
    It's complete enough to compile C11 programs - to me, that's as good of a benchmark as anything. The main thing qbe is missing for cproc's purposes is inline assembly and VLAs. DWARF support would also be nice, but no one seems to care enough to do the work yet.
    - dbcurtis 6y ago
      Are you saying that qbe does not generate any debug information, or just not DWARF format?
      - ddevault 6y ago
        qbe does not generate any debug information. Though you can pass some flags to get some ideas of its internal code generation process.
bluejekyll 6y ago
While the GP doesn’t state this as an advantage, the Rust community would benefit from a fully Rust toolchain.
- bluGill 6y ago
  Why? Other than to prove it can be done what is the point. If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources. There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe they will split resources that could be used to make something else better.
  - sambe 6y ago
    Why phrase it as "other than to prove it can be done" if you already know there are good answers? I think the following obviously do apply: 1) much easier for Rust community to contribute to the compiler from end-to-end. 2) lower coordination cost with LLVM giving complete, Rust-focussed control over code generation/optimisation. Think about e.g. fixing noalias. 3) lower maintenance cost for LLVM integration/fork. It's also obvious that this needs to be weighed against the loss of LLVM accumulated technology and contributors. This is easy to underestimate (although I think 2)/3) are also easy to underestimate).
    - bluGill 6y ago
      Because I don't think the possible good answers apply. Sure it is harder to contribute to the backend, but does it matter? I've been doing c++ for years and never looked at the backend. I'll grant lower coordination costs. However I believe they are not outweighed by the advantages of the other llvm contributions. If they need to fork llvm that is a problem. Either merge it back in and be done (with some tests so whatever they need is not broke), or there is a compelling reason as llvm won't work with their changes.
      - 6y ago
deleted 6y ago
[deleted]

I use qbe, it's great. Here's a mostly feature-complete C11 compiler based on qbe: https://git.sr.ht/~mcf/cproc https://git.sr.ht/~mcf/cproc

hawski 6y ago
I see that cproc is under quite heavy development, but qbe had last commit at the end of November. Is it considered feature complete? I heard about it some months ago and was quite interested in QBE, but it did not enjoy high tempo of changes. It may be considered advantage, I know too little to judge.
- ddevault 6y ago
  It's complete enough to compile C11 programs - to me, that's as good of a benchmark as anything. The main thing qbe is missing for cproc's purposes is inline assembly and VLAs. DWARF support would also be nice, but no one seems to care enough to do the work yet.
  - dbcurtis 6y ago
    Are you saying that qbe does not generate any debug information, or just not DWARF format?
    - ddevault 6y ago
      qbe does not generate any debug information. Though you can pass some flags to get some ideas of its internal code generation process.

bluejekyll 6y ago

While the GP doesn’t state this as an advantage, the Rust community would benefit from a fully Rust toolchain.

bluGill 6y ago
Why? Other than to prove it can be done what is the point. If rust was a huge community okay, but face it, they are not. It is better therefore to focus their efforts where they can make a difference. A new x where the existing ones are just fine (this includes well maintained) is a waste of resources. There are many possible good answers to the above question. However I'm not sure they apply, and worse I believe they will split resources that could be used to make something else better.
- sambe 6y ago
  Why phrase it as "other than to prove it can be done" if you already know there are good answers? I think the following obviously do apply: 1) much easier for Rust community to contribute to the compiler from end-to-end. 2) lower coordination cost with LLVM giving complete, Rust-focussed control over code generation/optimisation. Think about e.g. fixing noalias. 3) lower maintenance cost for LLVM integration/fork. It's also obvious that this needs to be weighed against the loss of LLVM accumulated technology and contributors. This is easy to underestimate (although I think 2)/3) are also easy to underestimate).
  - bluGill 6y ago
    Because I don't think the possible good answers apply. Sure it is harder to contribute to the backend, but does it matter? I've been doing c++ for years and never looked at the backend. I'll grant lower coordination costs. However I believe they are not outweighed by the advantages of the other llvm contributions. If they need to fork llvm that is a problem. Either merge it back in and be done (with some tests so whatever they need is not broke), or there is a compelling reason as llvm won't work with their changes.
    - 6y ago

deleted 6y ago

[deleted]