3 ms·

The Fil-C stack is composed of : - Userland: the place where you C code lives. Like the normal userland you're familiar with, but everything is compiled with F

The Fil-C stack is composed of : - Userland: the place where you C code lives. Like the normal userland you're familiar with, but everything is compiled with Fil-C, so it's memory safe. - Yololand: the place where Fil-C's runtime lives. Fil-C's runtime is about 100,000 lines of C code (almost entirely written by me), which currently has libc as a dependency (because the runtime makes syscalls using the normal C functions for syscalls rather than using assembly directly; also the runtime relies on a handful of libc utility functions that aren't syscalls, like memcpy). So Fil-C has two libc's. The yololand libc (compiled with a normal C compiler, only there to support the runtime) and the userland libc (compiled with the Fil-C compiler like everything else in Fil-C userland, and this is what your C code calls into).

skissane 1y ago
Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. Doesn’t work on some other operating systems (e.g. Solaris/Illumos, OpenBSD, macOS, Windows) where the system call interface is private to the system shared libraries
- pizlonator 1y ago
  > Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? Unless you do special things, the compiler turns __builtin_memcpy into a call to memcpy. :-) There is __builtin_memcpy_inline, but then you're at the compiler's whims. I don't think I want that. A faithful implementation of what you're proposing would have the Fil-C runtime provide a memcpy function so that whenever the compiler wants to call memcpy, it will call that function. > On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. I could do that. I just don't, right now. You're totally right that I could remove the yolo libc. This is one of like 1,000 reasons why Fil-C is slower than it needs to be right now. It's a young project so it has lots of this kind of "expedient engineering".
- imcritic 1y ago
  You keep repeating the name wrong: yololand, not yololand.
  - cryptonector 1y ago
    GP was saying 'yoyoland', when it's 'yololand' (as in YOLO?).
    - pizlonator 1y ago
      Yeah YOLO. I needed a fun term to refer to the C that isn’t Fil-C. I call it Yolo-C. Hence yololand - the part of the Fil-C process that contains a bit of Yolo-C code for the Fil-C runtime.
      - cryptonector 1y ago
        Thanks. I went looking and saw this in the Fil-C manifesto: > It's even possible to allocate memory using malloc from within a signal handler (which is necessary because Fil-C heap-allocates stack allocations). Hmm, really? All stack allocations are heap-allocated? Doesn't that make Fil-C super slow? Is there no way to do stack allocation? Or did I misread what you meant by 'stack allocations'?
        pizlonator 1y ago
        It’s a GC allocation, not a traditional malloc allocation. So slower than stack allocation but substantially faster than a malloc call. And that GC allocation only happens if the compiler can’t prove that it’s nonescaping. The overwhelming majority of what look like stack allocations in C are proved nonescaping. Consequently, while Fil-C does have overheads, this isn’t the one I worry about.
        cryptonector 1y ago
        I see! Thanks for that answer. I'm sure I'll have lots of questions, like these: You say you don't have to instrument malloc(), but somehow you must learn of the allocation size. How? Are aliasing bugs detected? I assume that Fil-C is a whole-program-only option. That is, that you can't mix libraries not compiled with Fil-C and ones compiled with Fil-C. Is that right? So one might want a whole distro built with Fil-C. How much are you living with Fil-C? How painful is it, performance-wise? BTW, I think your approach is remarkable and remarkably interesting. Of course, to some degree this just highlights how bad C (and C++) is (are) at being memory-safe.

skissane 1y ago

Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. Doesn’t work on some other operating systems (e.g. Solaris/Illumos, OpenBSD, macOS, Windows) where the system call interface is private to the system shared libraries

pizlonator 1y ago
> Why does yoyoland need to use libc’s memcpy? Can’t you just use __builtin_memcpy? Unless you do special things, the compiler turns __builtin_memcpy into a call to memcpy. :-) There is __builtin_memcpy_inline, but then you're at the compiler's whims. I don't think I want that. A faithful implementation of what you're proposing would have the Fil-C runtime provide a memcpy function so that whenever the compiler wants to call memcpy, it will call that function. > On Linux, if all you need is syscalls, you can just write your own syscall wrapper-like Go does. I could do that. I just don't, right now. You're totally right that I could remove the yolo libc. This is one of like 1,000 reasons why Fil-C is slower than it needs to be right now. It's a young project so it has lots of this kind of "expedient engineering".
imcritic 1y ago
You keep repeating the name wrong: yololand, not yololand.
- cryptonector 1y ago
  GP was saying 'yoyoland', when it's 'yololand' (as in YOLO?).
  - pizlonator 1y ago
    Yeah YOLO. I needed a fun term to refer to the C that isn’t Fil-C. I call it Yolo-C. Hence yololand - the part of the Fil-C process that contains a bit of Yolo-C code for the Fil-C runtime.
    - cryptonector 1y ago
      Thanks. I went looking and saw this in the Fil-C manifesto: > It's even possible to allocate memory using malloc from within a signal handler (which is necessary because Fil-C heap-allocates stack allocations). Hmm, really? All stack allocations are heap-allocated? Doesn't that make Fil-C super slow? Is there no way to do stack allocation? Or did I misread what you meant by 'stack allocations'?
      - pizlonator 1y ago
        It’s a GC allocation, not a traditional malloc allocation. So slower than stack allocation but substantially faster than a malloc call. And that GC allocation only happens if the compiler can’t prove that it’s nonescaping. The overwhelming majority of what look like stack allocations in C are proved nonescaping. Consequently, while Fil-C does have overheads, this isn’t the one I worry about.
        cryptonector 1y ago
        I see! Thanks for that answer. I'm sure I'll have lots of questions, like these: You say you don't have to instrument malloc(), but somehow you must learn of the allocation size. How? Are aliasing bugs detected? I assume that Fil-C is a whole-program-only option. That is, that you can't mix libraries not compiled with Fil-C and ones compiled with Fil-C. Is that right? So one might want a whole distro built with Fil-C. How much are you living with Fil-C? How painful is it, performance-wise? BTW, I think your approach is remarkable and remarkably interesting. Of course, to some degree this just highlights how bad C (and C++) is (are) at being memory-safe.