Right now Python simply does not work at all. I was trying last night just to get the compiler to build, but ran into some Fil-C panics at the last moment when it tries to "freeze" some modules? But it should work.

My idea is to move towards defining Fil-C as a "platform", meaning it would have its own ABI value, so it would look like a target called "x86_64-unknown-linux-filc", and then the magic of Nixpkgs is that it can instantiate a full realm called "pkgsCross.filc" which automatically has every package, whose packages are built on your ordinary non-FilC platform as a cross compilation.

When that works—I hope it works, I probably need help to get it working—you should be able to use all the Nixpkgs packaging helpers like

    pkgs.mkShell {
      packages = [
        (pkgsCross.filc.python3.withPackages (pypkgs: with pypkgs; [
          pandas
          requests
        ]))
      ];
    }

I should probably try to gather some interest among people who are truly familiar with Nixpkgs cross compilation...

That was my idea and I wrote a good chunk of the compiler and runtime.

Yeah, fat pointers are definitely a viable approach, but a lot of the existing C code that is the main argument for Fil-C assumes it can put a pointer in a long. (Most of the C code that assumed you could put it in an int has been flushed out by now, but that was a big problem when the Alpha came out.) I'm guessing that the amount of existing C code in Apple's bootloader is minimal, maybe 1000 lines, not the billions of lines you can compile with Fil-C.

You don't even need to reverse it. It's in the public clang, and I'm working on helping my team adopt it in some test cases.

And it's not just the bounds-checking that's great -- it makes a bunch of C anti-patterns much harder, and it makes you think a lot harder about pointer ownership and usage. Really a great addition to the language, and it's source-compatible with empty macro-definitions (with two exceptions).

A descendent of this is in clang as -fbounds-safety.

and the author of Fil-C worked on that!

Not for much longer, replacing it with Swift is one of the reasons why Swift Embedded subset came to be.

"Why Embedded Swift"

https://youtu.be/LqxbsADqDI4?t=144

It’s not so fundamental of a limitation.

Fil-C already allows memory mapped I/O in the form of mmap.

The only thing missing that is needed for kernel level MMIO is a way to forge a capability. I don’t allow that right now, but that’s mostly a policy decision. It also falls out from the fact that InvisiCaps optimize the lower by having it double as a pointer to the top of the capability. That’s also not fundamental; it’s an implementation choice.

It’s true that InvisiCaps will always disallow int to ptr casts, in the sense that you get a pointer with no capability. You’d want MMIO code to have some intrinsic like `zunsafe_forge_ptr` that clearly calls out what’s happening and then you’d use that wherever you define your memory mapped registers.

Check out this document to see how the Fil-C ports of Python and Perl and so on work:

https://github.com/mbrock/filnix/blob/main/ports/analysis.md

This is still within the userspace application realm but it's good to know that Fil-C does have explicit capability-preserving operations (`zxorptr`, `zretagptr`, etc) to do e.g. pointer tagging, and special support for mapping pointers to integer table indices and back (`zptrtable`, etc).

Yes, I think that's reasonable. I imagine you wouldn't have to extend Fil-C very much to sneak some memory-mapped I/O addresses into your program, but maybe having the garbage collector pause the program in the middle of an interrupt handler would have other bad effects. Like, if you were generating a video signal, you'd surely get display glitches.

You don't have to do int2ptr for mmio or absolute addresses, you can punt that to the linker.

    extern struct uart UART0;

UB was added to C when it was 15 years old, and the current understanding of UB is from about 10 years after that. It isn't essential to C; an implementation that defines all the undefined behavior would still be compliant and capable of running nearly all existing C.

> There is a perf penalty from GC.

Not really, no. There's a perf penalty from bounds checking and runtime type checking. GC takes a little time but saves you time on free(), although it only becomes a real performance win when you remove the other, less efficient ways of tracking lifetimes, such as reference counting.

> Plus you need all the original sources, right?

Yes, but from my point of view, loss of sources is not a significant problem. I know it happened historically, especially last millennium, but really only for proprietary software running on a single platform such as MS-DOS. Unix software, free software, and software using source control systems have suffered almost no source code loss, except for particular old versions.

> Declining usage of C is going to make you lose intellectual heritage

I think there are more C programmers today than there have ever been, and I doubt that that number will ever fall to zero while there are still humans.

> you might as well use C# or Go

Except, uh, you can't use C# or Go to run a program written in C/C++.

Oh, you mean we can solve all our problems by simply rewriting all legacy software? Right, I forgot!

Good to see you back! I hope you're doing okay; I know you ran into some real trouble a couple of years ago.

Hey Filip – while we're talking about memory architecture, have you started looking at ARM's EMTE extension (e.g https://security.apple.com/blog/memory-integrity-enforcement...)? Could it eventually replace invisicaps?

If you're taking votes, I would vote for AArch64 next. :D

It is implemented via LLVM.

That's good to know!

C is immensely powerful, portable and probably as fast as you can go without hand-coding in the architecture-specific assembly. Most of the world's information systems (our cyberstructure) rely directly or indirectly on C. And don't get me wrong, I'm a great enthusiast of the idea of sticking to memory-safe languages like Rust from now on.

The hard truth is will live with legacy C code, period. Pizlo's heroic effort bridges the gap so to speak, it kind of sandboxes userspace C in a way that inherently adds memory safety to legacy code. There are only a few corner cases now that can't be bothered by any slow-down vis-a-vis unsafe C, and the great majority of code across every industry would benefit much more from the reduced surface of exposure.

I'd love to see some practical benchmarks for programs such as grep and other binutils. I'm also pretty curious if it turns up any bugs in them in use.

> 4x is at the upper end of the overheads

This is already quite impressive. Many automatic memory managed languages have more than 4x worst-case slowdown. E.g. Google-backed Golang is ~1.5× to ~4× slower than optimized C++. I suppose there are many ways to further speed-up Fil-C if more resources were given to the project.

Still much better than C will ever be, even if I disagree with some of its design decisions.

There were several options, but the industry decided to bet on UNIX and C as main inspiration going forwards from the 1980's.

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"

Guess what he means by "1980 language designers and users have not learned this lesson".