4 ms·

On the same way than cproc+QBE I guess, 70% of gcc speed in my benchmarks. The more real-life alternatives to those abominations of gcc and clang, the merrier.

On the same way than cproc+QBE I guess, 70% of gcc speed in my benchmarks. The more real-life alternatives to those abominations of gcc and clang, the merrier. I wish the linux kernel devs did care to keep the door _reasonably_ open for such compilers (with assembler source files as alternative to inline assembly, some extensions avoidance and niche expensive compiler features). This is another case of why super complex syntax computer languages should be avoided like hell (c++, rust, etc).

pjmlp 2y ago
Circle frontend, that includes all C++17 (when it was current) and the Rust related extensions, was implemented by a single guy.
- sitkack 2y ago
  Relativity was discovered by a single guy.
  - pjmlp 2y ago
    Which confirms complex matters aren't an issue, being able to handle them might be.
    - sylware 2y ago
      wrong, point missed by miles away. Maybe, "normal"/"average" devs would help you to get the point.
      - pjmlp 2y ago
        Those can keep up with Go, as per the language authors point of view regarding target audience.
        sylware 2y ago
        AI????
  - ninalanyon 2y ago
    Not really. Relativity goes back to Galileo at least, and it's development by Einstein relied on Lorentz and Riemann among others. Science really is a process of /standing on the shoulders of giants/ as Newton is reputed to have said. That doesn't diminish Einstein's achievement of course.
    - sitkack 2y ago
      I made a facetious comment to parry that of pjmlp, whom also made a facetious comment wrt to compiler complexity and what "one person" can do. https://github.com/seanbaxter/circle https://github.com/seanbaxter/circle It is like if one tried claiming that Fabrice Bellard was an example of a median dev. The number of C++ compilers written by one person is one. And because of this, it gives us no predictive power in what pjmlp was trying to assert. I agree with you, Albert and Lorentz and Riemann got caught in the rhetorical crossfire.
      - mingodad 2y ago
        Not exactly the same but here https://github.com/robertoraggi/cplusplus https://github.com/robertoraggi/cplusplus there is one person serious effort to create a C++-23 compiler front end.
        fuhsnn 2y ago
        It does look serious, and is able to parse one simple case I got at hand that openwatcom and orangec failed, thanks for bringing it up.
- sylware 2y ago
  You mean Circle can output correct intermediate code for the latest gcc code? Or valve mesa aco code?
  - pjmlp 2y ago
    That frontend plugs into LLVM for the IR to machine code part, no need for GCC. It replaces clang, it is not a fork of it.
    - sylware 2y ago
      I thought it was using libfirm... not that c++ diarrhea of llvm... :(
sitkack 2y ago
QBE is ... problematic. The source has no comments, single letter variable names. It is not written to be extended by anyone else other than the author. I would recommend libfirm over QBE by at least 10km. https://libfirm.github.io/ https://libfirm.github.io/ https://github.com/libfirm/libfirm https://github.com/libfirm/libfirm
- contificate 2y ago
  On the topic of QBE, I've always felt that someone aiming to do the same scope of project ought to make their IR a syntactic subset of LLVM IR. If you do that, your test suite can involve invoking LLVM for a comparison. As for QBE itself, many of the core transformations are fairly standard, which makes it somewhat more approachable for me (e.g. Cooper et al's dominance algorithm, Rideau et al's parallel moves algorithm, etc.). Of course, this doesn't negate the fact that it's not as "hackable" as they probably intended.
- kragen 2y ago
  It won't surprise you to learn that I'm always interested in hearing about alternatives to QBE, but from the documentation, libfirm sounds more like a heavyweight alternative to LLVM, not a lightweight alternative to QBE. How big is it?
  - sitkack 2y ago
    9x larger in LoC, 50x larger in comments. I had a wall of supporting tokei but decided against it, but the short of it is, LLVM is phenomenally massive, and libfirm at 135kloc and 35kloc of comments is but a raindrop that is in the 15Mloc+ that is LLVM. Perhaps instead of looking towards libfirm, we should look at cranelift. It is of comparable size and actually includes 12kloc of documentation, not just comments. https://github.com/bytecodealliance/wasmtime/tree/main/cranelift https://github.com/bytecodealliance/wasmtime/tree/main/crane...
    - kragen 2y ago
      If it's roughly an order of magnitude more complexity than QBE, it doesn't sound like an alternative, even if it's still two orders of magnitude smaller than LLVM. Cranelift has been looking interesting. Also, LuaJIT.

pjmlp 2y ago

Circle frontend, that includes all C++17 (when it was current) and the Rust related extensions, was implemented by a single guy.

sitkack 2y ago
Relativity was discovered by a single guy.
- pjmlp 2y ago
  Which confirms complex matters aren't an issue, being able to handle them might be.
  - sylware 2y ago
    wrong, point missed by miles away. Maybe, "normal"/"average" devs would help you to get the point.
    - pjmlp 2y ago
      Those can keep up with Go, as per the language authors point of view regarding target audience.
      - sylware 2y ago
        AI????
- ninalanyon 2y ago
  Not really. Relativity goes back to Galileo at least, and it's development by Einstein relied on Lorentz and Riemann among others. Science really is a process of /standing on the shoulders of giants/ as Newton is reputed to have said. That doesn't diminish Einstein's achievement of course.
  - sitkack 2y ago
    I made a facetious comment to parry that of pjmlp, whom also made a facetious comment wrt to compiler complexity and what "one person" can do. https://github.com/seanbaxter/circle https://github.com/seanbaxter/circle It is like if one tried claiming that Fabrice Bellard was an example of a median dev. The number of C++ compilers written by one person is one. And because of this, it gives us no predictive power in what pjmlp was trying to assert. I agree with you, Albert and Lorentz and Riemann got caught in the rhetorical crossfire.
    - mingodad 2y ago
      Not exactly the same but here https://github.com/robertoraggi/cplusplus https://github.com/robertoraggi/cplusplus there is one person serious effort to create a C++-23 compiler front end.
      - fuhsnn 2y ago
        It does look serious, and is able to parse one simple case I got at hand that openwatcom and orangec failed, thanks for bringing it up.
sylware 2y ago
You mean Circle can output correct intermediate code for the latest gcc code? Or valve mesa aco code?
- pjmlp 2y ago
  That frontend plugs into LLVM for the IR to machine code part, no need for GCC. It replaces clang, it is not a fork of it.
  - sylware 2y ago
    I thought it was using libfirm... not that c++ diarrhea of llvm... :(

sitkack 2y ago

QBE is ... problematic. The source has no comments, single letter variable names. It is not written to be extended by anyone else other than the author. I would recommend libfirm over QBE by at least 10km. https://libfirm.github.io/ https://libfirm.github.io/ https://github.com/libfirm/libfirm https://github.com/libfirm/libfirm

contificate 2y ago
On the topic of QBE, I've always felt that someone aiming to do the same scope of project ought to make their IR a syntactic subset of LLVM IR. If you do that, your test suite can involve invoking LLVM for a comparison. As for QBE itself, many of the core transformations are fairly standard, which makes it somewhat more approachable for me (e.g. Cooper et al's dominance algorithm, Rideau et al's parallel moves algorithm, etc.). Of course, this doesn't negate the fact that it's not as "hackable" as they probably intended.
kragen 2y ago
It won't surprise you to learn that I'm always interested in hearing about alternatives to QBE, but from the documentation, libfirm sounds more like a heavyweight alternative to LLVM, not a lightweight alternative to QBE. How big is it?
- sitkack 2y ago
  9x larger in LoC, 50x larger in comments. I had a wall of supporting tokei but decided against it, but the short of it is, LLVM is phenomenally massive, and libfirm at 135kloc and 35kloc of comments is but a raindrop that is in the 15Mloc+ that is LLVM. Perhaps instead of looking towards libfirm, we should look at cranelift. It is of comparable size and actually includes 12kloc of documentation, not just comments. https://github.com/bytecodealliance/wasmtime/tree/main/cranelift https://github.com/bytecodealliance/wasmtime/tree/main/crane...
  - kragen 2y ago
    If it's roughly an order of magnitude more complexity than QBE, it doesn't sound like an alternative, even if it's still two orders of magnitude smaller than LLVM. Cranelift has been looking interesting. Also, LuaJIT.