[ihnorton]

Skimming the docs, I was surprised to see that there appears to be no built-in support for foreign function calls to C libraries ("It's a bold strategy Cotton...")

This makes more sense in light of a comment by the author in a previous discussion about C ABIs [1]:

> Virgil compiles to tiny native binaries and runs in user space on three different platforms without a lick of C code, and runs on Wasm and the JVM to boot. [...] No C ABI considerations over here.

[1] https://news.ycombinator.com/item?id=30705383

[titzer]

Indeed, I've wanted to see how far I can get rebuilding userspace from the ground up. Virgil does that by exposing a raw syscall primitive on each target architecture, so when you target x86-linux you get "Linux.syscall<T>(int, T)". The compiler knows the calling convention of the kernel on each target platform, so it just puts things in the right registers and does "int 80" or "syscall". So library and runtime code that implements I/O, signals, etc just dial up the syscalls they want to get off the ground. So there's no need to resort to assembly; I view asm as the compiler's job.

[vlovich123]

Doesn’t that not work on many OSes since they treat libc as the stable ABI surface and make no guarantees about the syscall interface? If I recall correctly that’s what gave Go so many headaches on MacOS as they chose a similar strategy until, if I recall correctly, they abandoned it in recognition that it’s not tenable.

[titzer]

> since they treat libc as the stable ABI surface

For the subset that Virgil uses to get off the ground, I haven't been broken by the kernel changing system calls. MacOS has been a pain for a number of other reasons though, not the least of which is deprecating 32-bit altogether...with a student's help I finally got around to generating x86-64 Mach-O binaries. That works on x86 macs again. But something is still wonky and they don't run under Rosetta 2.

Linux is rock solid though. I've never been broken by the kernel.

[vlovich123]

That’s because Linux is very unique in treating the syscall boundary as the ABI. I’m not sure which other OSes do that. Maybe Windows? Not sure. Certainly none of the BSDs.

[matheusmoreira]

Linux is the only operating system that guarantees kernel binary interface stability. You can discard the entire user space and write dependency-free software that interfaces with Linux directly. You can even boot Linux straight into your own program and bring up the system yourself.

This single function is all you need to do literally anything on x86_64 Linux from writing to a file descriptor to graphics card ioctls:

https://github.com/matheusmoreira/liblinux/blob/master/sourc...

In all others, interfacing with the kernel directly eventually leads to breakage because the people in charge change the system calls. Go binaries broke on OS X because of this. We're not meant to bypass their system libraries.

[asimpletune]

That’s crazy that other os’s don’t do that

[vlovich123]

It’s not that crazy when you consider that C has been the lingua franca of OS development for 50 years with a very thin library interface that’s been ported to every single platform under the sun. That’s a pretty sane maintenance choice all things considered since every single other language linked against libc for those 50 years, especially since the underlying hardware and OS has evolved (easier to maintain a highly standardized C library with the high level semantics you wish to standardize vs magic values in registers that are fixed for the duration of that platform and sometimes even across platforms.

I think Go was the first language that tried to buck that trend and it did not go well (aside from Linux).

[formerly_proven]

Windows doesn't

[NonEUCitizen]

What is the definition of "tiny" here? 10's of KB? Thanks.

[titzer]

The smallest x86-linux binary, without runtime or GC, is 248 bytes. With runtime 6KiB, with runtime and GC, 11KiB.