Remix.run Logo
pizlonator 3 days ago

I’ve been thinking about this problem since 2004.

Here’s a rough timeline:

- 2004-2018: I had ideas of how to do it but I thought the whole premise (memory safe C) was idiotic.

- 2018-2023: I no longer thought the premise was idiotic but I couldn’t find a way to do it that would result in fanatical compatibility.

- 2023-2024: early Fil-C versions that were much less compatible and much less performant

- end of 2024: InvisiCaps breakthrough that gives current fanatical compatibility and “ok” performance.

It’s a hard problem. Lots of folks have tried to find a way to do it. I’ve tried many approaches before finding the current one.

remexre 3 days ago | parent | next [-]

Beyond the Git history, is there any write-up of the different capability designs you've gone with?

I'm interested in implementing a safe low-level language with less static information around than C has (e.g. no static pointer-int distinction), but I'd rather keep around the ability to restrict capabilities to only refer to subobjects than have the same compatibility guarantees Invisicaps provide, so I was hoping to look into Monocaps (or maybe another design, if there's one that might fit better).

pizlonator 3 days ago | parent [-]

I summarize past attempts in https://fil-c.org/invisicaps

aw1621107 3 days ago | parent | prev [-]

That's a really interesting timeline! Sounds like it's been stewing for a lot longer than I expected. Was there anything in particular around 2018 that changed your opinion on the idiotic-ness of the premise?

If a hypothetical time machine allowed you to send the InvisiCaps idea back to your 2004-era self, do you think the approach would have been feasible back then as well?

pizlonator 2 days ago | parent [-]

> Was there anything in particular around 2018 that changed your opinion on the idiotic-ness of the premise?

The observation that the C variants used on GPUs are simplistic takes on memory safe C