I really didn't expect that from the land of freedom. /s
Readit News> still is the main company behind LLVM.
lol people really say whatever comes to their mind around here don't they? I'm pretty sure all of the companies associated with these targets would strongly disagree with you
https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...
- lol people really say whatever comes to their mind around here don't they?
Apple literally hired Chris Lattner in 2005 and made a team to work on LLVM. After GNU refused to integrate LLVM into GCC,
But Apple saw an opportunity to have its own C/C++ compiler.
To this day, Apple still has one core team working on LLVM.
Anyone can come in, add a feature/target, and then leave the project. But a of lot LLVM maintainers are hired by or indirectly big tech companies.
> And that is the abi followed by pretty much any Unix successor: Linux, Apple's OS, FreeBSD.
Even limiting that to “on x64”, I don’t see how that’s true. To make a syscall, the ABI on Linux says “make the call”, while MacOS (and all the BSDs, I think) says “call the provided library function”.
Also (https://developer.apple.com/documentation/xcode/writing-64-b...): “Apple platforms typically follow the data representation and procedure call rules in the standard System V psABI for AMD64, using the LP64 programming model. However, when those rules are in conflict with the longstanding behavior of the Apple LLVM compiler (Clang) on Apple platforms, then the ABI typically diverges from the standard Processor Specific Application Binary Interface (psABI) and instead follows longstanding behavior”
Some of the exceptions mentioned there are:
- Asynchronous Swift functions receive the address of their async frame in r14. r14 is no longer a callee-saved register for such calls.
- Integer arguments that are smaller than int are required to be promoted to int by the caller, and the callee may assume that this has been done. (This includes enumerations whose underlying type is smaller than int.) For example, if the caller passes a signed short argument in a register, the low 32 bits of the register at the moment of call must represent a value between -32,768 and 32,767 (inclusive). Similar, if the caller passes an unsigned char argument in a register, the low 32 bits of the register at the moment of call must represent a value between 0 and 255 (inclusive). This rule also applies to return values and arguments passed on the stack.
Swift has its own ABI and calling convention, so that makes sense that Apple adapted to it.
The system v abi doesn't say anything about syscall.
Windows x86_64 abi is the same abi for x86, for this reason, you can only pass arguments in 4 registers ( while unix uses 6 ) because x86 only had 8 registers.
I think people have expectations that are misaligned with history and reality about this, to be honest. We can't expect all OS to do things in the same way.
C was created to rewrite the UNIX system, and POSIX compliance is followed by all successors, with minimal differences.
When it became clear that "Itanium" was a failure, Microsoft couldn't just pull an ABI out of the box and break all applications, so they just reused the same x86 ABI.
There are upsides to this approach. Coupling Swift's AST with Clang's AST will allow for the best codgen, for sure.
However, the huge downside to this approach, which cannot be overlooked, is that Clang (not libclang) is not designed to be a library. It doesn't have the backward compatibility of a library. Swift (i.e. Apple) is already deep into developing Clang, and so I'm sure they can afford the cost of keeping up with the breaking changes that happen on every Clang release. For a solo dev, I'm not yet sure this is actually viable, but I will give it more consideration.
However, I think that raising alarms at C++ codegen is unwarranted. As I said before, basically any query builder or codegen takes some form of string generation. The way we make those safe is to add types in front of them, so we're not just formatting user strings into other strings. That's exactly what CppInterOp does, where the types added are Clang QualTypes and Decls.
You right.
Always good to remember that Apple was and still is the main company behind LLVM.
Swift was built and its maintained by the same time that worked in LLVM.
And also, Swift has its own fork of LLVM and LLVM has built-in a lot of features designed for swift like calling convention and async transformation.
The amount of features swift has and is releasing at the same time it has its own LLVM version is just not a thing you can do without a lot of money and years of accumulated expertise.
There is one pretty serious C++ parser project: https://github.com/robertoraggi/cplusplus
Wow, thanks!
I didn't know this project.
To parse C++ you need to perform typecheck and name resolution at the same time. And C++ is pretty complex so it's not a easy task.
Linking directly to C++ is truly hell just considering symbol mangling. The syntax <-> semantics relationship is ghastly. I haven't seen a single project tackle the C++ interface in its entirety (outside of clang). It nearly seems impossible.
There's a reason Carmack tackled the C abi and not whatever the C++ equivalent is.
Just parsing C++ is already a freaking hell.
It's no wonder that every other day a new mini C compiler drops in, while no one even attempts to parse C++.
That's great!
Interop with C++ is such a complex task. Congratss on your work! It's definitely not an easy thing.
I've always wondered what is the best way to interact with C++ template instantiation while keeping performance.
For a static language, you'd probably need to translate your types to C++ during compilation, ask Clang/GCC/MSVC to compile the generated C++ file, and then link the final result.
And finally, pray to the computer gods that name mangiling was done right.
There is no C ABI (windows compilers do things quite differently from linux ones, etc) and there is no certainly no C++ equivalent.
C ABI is the system V abi for Unix, since C was literally created for it. And that is the abi followed by pretty much any Unix successor: Linux, Apple's OS, FreeBSD.
Windows has its own ABI.
The different abi is pretty much legacy and the fact that x86_64 ABI was built by AMD + Linux etc, while Microsoft worked with Intel for the Itanium abi.
Rust has types that don't allow contraction, too: e.g., String, vectors and boxes.
Their being that way is essential for the borrow checker to provide the memory-safety guarantees it provides.
Yep, that's true.
But multiple immutable shared references are a form of contraction, while mutable references are actually affine.
Swift doesn't have references like Rust, and you can't even have unsafe raw pointers to variables without producing a dangling pointer, but this makes Swift more restrictive and less powerful than Rust.
So, you will still need a borrow checker for the same reasons Rust needs one, and C/C++ also needed.