Stream: compiler development

Topic: C ABI for platforms

Richard Feldman (Oct 17 2023 at 00:42):

so Folkert and I were talking about the neverending source of bugs and safety that is trying to correctly implement the C ABI for host-exposed functions, and we ended up deciding to make this change:

• the new way host-exposed functions work is that they all accept exactly two pointers (and "return" nothing)
• one pointer points to the return value
• the other pointer points to all the arguments, which should be stored as a struct
• the caller allocates space for both of these on its stack
• the caller populates the arguments struct
• after the host-exposed function completes, it will write into the return struct (just like the _generic version does today)

Richard Feldman (Oct 17 2023 at 00:42):

this means that the amount of time we spend messing around with C ABI problems immediately goes to zero and stays there

Richard Feldman (Oct 17 2023 at 00:43):

the downside is that it's some amount less efficient than using the C ABI

Richard Feldman (Oct 17 2023 at 00:44):

given the (very small) magnitude of that performance delta, and the (very large) magnitude of the (implementation cost + bugs everyone has to deal with until we sort them out) delta, maybe someday it will seem like a reasonable project to implement the whole C ABI, but for now this seems like a better tradeoff all around

Richard Feldman (Oct 17 2023 at 00:45):

oh, and of course glue can take care of generating these calls anyway, and wrap them in something that looks appropriate for the native host language

Brendan Hansknecht (Oct 17 2023 at 03:29):

I know I am thinking at least medium term here, but once we get the async state machine where everything is returned via main, won't a lot of this pain go away. No more arbitrary function calling. Just one single tag union return from main.

Brendan Hansknecht (Oct 17 2023 at 03:30):

Also, this idea is probably mostly ok if the data is stack allocated. Given io is a boundary it probably isn't called "too" much.

Brendan Hansknecht (Oct 17 2023 at 03:31):

Plus will probably help unlock new platforms, and more language glue wrappers faster, which is a huge boon

Luke Boswell (Oct 17 2023 at 06:07):

I know this is a little off-topic, and may be obvious... but if I have something like a List U8 in the return struct does it need to have a predetermined size? Or would I simply give it an initialised empty list (like now), and roc_alloc would assign more memory if needed?

Does this decision help with the unknown size problem that was not yet resolved?

Brendan Hansknecht (Oct 17 2023 at 06:38):

I'm essentially certain the caller would just allocate the size of the list pointer, size, and capacity. It would not care about any of the actual data in the list or its size. So you would just give the roc function 24 bytes of stack space. Roc would allocate the list and fill in those 24 bytes. After that, the host can access the list.

Brendan Hansknecht (Oct 17 2023 at 06:39):

I don't think you should even initialize the list. Just give it uninitialized bytes for roc to store the initialized list in later.

Last updated: Jul 26 2025 at 12:14 UTC