Conversation

This is a future I want to see – an ABI where types are preserved:

Quote Tweet

· Jul 23, 2020

Fifth: The ABI should include the ability to encode information about types and layouts, not just function names. This should be used at compile/runtime to provide type information. Compilers should be able to import ABI libraries directly, or provide codegen tools to get headers

Show this thread

Andy Kitchen

@auastro

Jul 24, 2020

The quoted proposal seems a lot like a reinvention of RPC. However most RPC systems today have fairly weak ad-hoc type systems.

Brendan Zabarauskas

@brendanzab

Jul 24, 2020

Yeah, it's pretty similar. I'm guessing this would match a wishlist of a nice RPC thing pretty closely. It's also definitely not a new idea - see some of the things I linked here:

Quote Tweet

Brendan Zabarauskas

@brendanzab

· Jul 24, 2020

Replying to @bitshiftmask

Regarding typed ABIs, have you seen the work on type preserving compilation and linking types? Would be cool to look into this stuff: eg. not sure how up to date this is, but there's interesting stuff here: silc.ccs.neu.edu/projects/ (@aatxe linked me to this ages ago).

Replying to

and

Mesa also preserved types until link time I think? I'm not sure if it was present in the ABI though, and I doubt it would have everything on the wishlist, like the versioning stuff (I'm no expert on that history though).

4:05 AM · Jul 24, 2020Twitter Web App

Replying to

and

But yeah, I don't think it's entirely fair to say that it's a reinvention - and even if it was I'm fine with that! So long as I get it in my compilers and languages! Trying to shoe-horn every FFI thing into the C ABI is really frustrating! 😆

Andy Kitchen

@auastro

Jul 24, 2020

Well put another way a synchronous zero-copy shared-memory RPC is effectively also a kind of ABI. The focus on ABI is a bit confusing to me though, couldn't you use the system ABI with added entry point metadata?

Show replies