Wow, this I must not’ve been paying attention to the libc portion of this, because it’s growed up into a really interesting cross-platform library, including some unexpected features like RAII/defer:
_gc: Frees memory when function returns.
This garbage collector overwrites the return address on the stack so that the RET instruction calls a trampoline which calls free(). It’s loosely analogous to Go’s defer keyword rather than a true cycle gc.
Good golly miss Molly.
My next question is how feasible it is to use this in higher level code that sits atop other C/++ libraries — I suspect those libraries will have to be tweaked for Cosmo compatibility first. (Especially big/complex ones like, in my case, Cap’nProto.)
I agree that the cross-platform library component is pretty cool, and keeps getting more powerful.
I bet that porting another language runtime to run on top of Cosmopolitan (like GNU or LLVM C++) is challenging. I think you’d have to recompile the C++ runtime of your choice from source against cosmopolitan libc, patching the sources to eliminate glibc dependencies. Like what is done to host LLVM on top of musl libc, for example. So probably somebody has to do a C++ Cosmopolitan implementation before it’s ready for Cap’nProto.
Cosmo only builds on Linux right now, but you can run the binaries you create anywhere. Cosmopolitan Libc is not ABI compatible with Musl or Glibc. For example, we’ve added fields like st_birthtim to struct stat to preserve data from different platforms like BSDs. The cosmoc++ toolchain script uses -nostdlib -nostdinc for that reason.
Disagree. Multiple binaries are big enough problem that Apple created fat binary. Linux also needs it, and there is FatELF, but it is not adopted. Typical Linux failure.
It’s really not clear to me why Apple did fat binaries, I suspect it was for compatibility with the exec family of system calls. NeXT had fat bundles with a different directory for every platform and architecture, allowing them to share resources and be thinned by just deleting some bits. Apple’s file format doesn’t give a space saving over this: they just concatenate the two binaries and slap a header on them. The Windows version allows sharing sections between the two (very useful for data, somewhat useful for code where the 32- and 64-bit versions of some x86 functions are the same). FatELF works the same way as the Apple versions and it’s really not clear to me what problem it solves: the number of situations where I want to provide a single download for multiple architectures on Linux/FreeBSD is very limited: people generally don’t provide a single binary for multiple Linux distributions, let alone architectures.
Cosmopolitan is interesting as a common platform that, in addition to providing a common binary, provides the same API independent of the underlying kernel. Once you have that, and (as they do) the ability to run the same functions on every platform with the same architecture, their form of fat binary becomes interesting because it’s only very slightly fatter than a single platform binary.
NeXTSTEP did have fat Mach-Os for a long while, identical to how modern macOS does it. The different directories were only for platform.
Regardless of how you do it (bundles or fat binaries), it makes it easier for things like Migration Assistant - snarf the entire contents of /Applications onto your new machine, and use the native slice on the new machine.
Regardless of how you do it (bundles or fat binaries), it makes it easier for things like Migration Assistant - snarf the entire contents of /Applications onto your new machine, and use the native slice on the new machine.
That’s true. I have done that for PowerPC to Intel, and was bitten by how well Rosetta worked: I thought the Core 2 was pretty slow because it wasn’t running VLC much faster than the G4. It turned out that VLC was not a fat binary and was just a PowerPC build. That’s not been an issue on other *NIX, because I do the migration by dumping the list of installed packages and installing it on the new machine. It’s also not an issue on iOS because the App Store does something equivalent.
Aiui, Cosmopolitan is a crossplatform bootloader for x86-64 binaries; it does not solve the same problem as universal binaries or FatELF, which is cross-architecture compatibility. They also take fundamentally different approaches, one embedding multiple compiled binaries, the other embedding an architecture-sensitive stub at the start.
You could maybe combine Cosmo with FatELF to get a cross-platform cross-architecture binary. But for true cross-architecture write-once-run-anywhere, what you want instead is some sort of low-level “portable assembly” that is compiled on the target, like JVM or CLR - at which point you don’t need Cosmo anymore.
The fact that it uses nsync for synchronisation primitives is interesting to me, because AFAIK glibc’s implementation of condition variables is still subtly broken. I wonder if nsync’s is correct? :)
Probably should clarify that it is x86_64 solution only, cross-platform thing is quite awesome but 2022 demands that architecture is to be stated since arm64 is quite widespread now.
Wow, this I must not’ve been paying attention to the libc portion of this, because it’s growed up into a really interesting cross-platform library, including some unexpected features like RAII/defer:
Good golly miss Molly.
My next question is how feasible it is to use this in higher level code that sits atop other C/++ libraries — I suspect those libraries will have to be tweaked for Cosmo compatibility first. (Especially big/complex ones like, in my case, Cap’nProto.)
I agree that the cross-platform library component is pretty cool, and keeps getting more powerful.
I bet that porting another language runtime to run on top of Cosmopolitan (like GNU or LLVM C++) is challenging. I think you’d have to recompile the C++ runtime of your choice from source against cosmopolitan libc, patching the sources to eliminate glibc dependencies. Like what is done to host LLVM on top of musl libc, for example. So probably somebody has to do a C++ Cosmopolitan implementation before it’s ready for Cap’nProto.
Cosmopolitan Libc has libcxx now. You can give those things a try with our new
CXX=cosmoc++toolchain script. https://github.com/jart/cosmopolitan/blob/master/tool/scripts/cosmoc%2B%2BAlso the Burrows of the Burrows–Wheeler transform which is how I know the name because I work in data platforms.
Thanks! Does this work because Cosmopolitan Libc is ABI compatible with Musl Libc on Linux? (Does cosmoc++ only work on Linux?)
Cosmo only builds on Linux right now, but you can run the binaries you create anywhere. Cosmopolitan Libc is not ABI compatible with Musl or Glibc. For example, we’ve added fields like
st_birthtimtostruct statto preserve data from different platforms like BSDs. Thecosmoc++toolchain script uses-nostdlib -nostdincfor that reason.Of all the myriad problems of multi-platform software, having multiple binaries is the absolute least interesting or encumbering.
This also solves cross compilation/multiple toolchains - which are definitely annoying things.
Disagree. Multiple binaries are big enough problem that Apple created fat binary. Linux also needs it, and there is FatELF, but it is not adopted. Typical Linux failure.
It’s really not clear to me why Apple did fat binaries, I suspect it was for compatibility with the exec family of system calls. NeXT had fat bundles with a different directory for every platform and architecture, allowing them to share resources and be thinned by just deleting some bits. Apple’s file format doesn’t give a space saving over this: they just concatenate the two binaries and slap a header on them. The Windows version allows sharing sections between the two (very useful for data, somewhat useful for code where the 32- and 64-bit versions of some x86 functions are the same). FatELF works the same way as the Apple versions and it’s really not clear to me what problem it solves: the number of situations where I want to provide a single download for multiple architectures on Linux/FreeBSD is very limited: people generally don’t provide a single binary for multiple Linux distributions, let alone architectures.
Cosmopolitan is interesting as a common platform that, in addition to providing a common binary, provides the same API independent of the underlying kernel. Once you have that, and (as they do) the ability to run the same functions on every platform with the same architecture, their form of fat binary becomes interesting because it’s only very slightly fatter than a single platform binary.
NeXTSTEP did have fat Mach-Os for a long while, identical to how modern macOS does it. The different directories were only for platform.
Regardless of how you do it (bundles or fat binaries), it makes it easier for things like Migration Assistant - snarf the entire contents of
/Applicationsonto your new machine, and use the native slice on the new machine.That’s true. I have done that for PowerPC to Intel, and was bitten by how well Rosetta worked: I thought the Core 2 was pretty slow because it wasn’t running VLC much faster than the G4. It turned out that VLC was not a fat binary and was just a PowerPC build. That’s not been an issue on other *NIX, because I do the migration by dumping the list of installed packages and installing it on the new machine. It’s also not an issue on iOS because the App Store does something equivalent.
Aiui, Cosmopolitan is a crossplatform bootloader for x86-64 binaries; it does not solve the same problem as universal binaries or FatELF, which is cross-architecture compatibility. They also take fundamentally different approaches, one embedding multiple compiled binaries, the other embedding an architecture-sensitive stub at the start.
You could maybe combine Cosmo with FatELF to get a cross-platform cross-architecture binary. But for true cross-architecture write-once-run-anywhere, what you want instead is some sort of low-level “portable assembly” that is compiled on the target, like JVM or CLR - at which point you don’t need Cosmo anymore.
The fact that it uses nsync for synchronisation primitives is interesting to me, because AFAIK glibc’s implementation of condition variables is still subtly broken. I wonder if nsync’s is correct? :)
Mike Burrows wrote *NSYNC. He’s known for coding Chubby and Altavista. So you know it’s going to be good.
Probably should clarify that it is x86_64 solution only, cross-platform thing is quite awesome but 2022 demands that architecture is to be stated since arm64 is quite widespread now.