"Conventions are implementation defined and would require patches to the compiler to add new ones."
Is the implementation of a Convention isolated enough that it would make sense to be extensible?
One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
If it could handle a longjmp() as well, then the new Convention would also do whatever setup (manipulate some global variables and call setjmp()) so that the caller doesn't have to worry about the longjmp().
The challenge with handling longjmp() in rust is that you can't call setjmp() as a normal FFI function (because it can return twice, like fork(), which is not a normal control flow). Also, longjmp()ing into rust code is just not defined behavior, even if it "works" for now. I assume there are similar challenges in Ada.
Is the implementation of a Convention isolated enough that it would make sense to be extensible?
Conventions are currently implemented in GNAT as a part of the parser/lexer just like any other syntax element, so it's not easily separated from the rest of the compiler. You could change that behavior, but that's not a small task. I don't think new calling conventions come along very often, so it seems unlikely to be worth the effort.
One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
I don't know the details of the Postgres implementation, but this sounds to me like the sort of thing that would work well as a generic procedure.
GNAT doesn't use runtime FFI, it dynamically links libraries and maps them into memory the same as any other C program that uses gcc and binutils. I think this makes what you're describing possible, but I'm not familiar enough with how setjmp/longjmp interacts with the stack to be certain without doing more research and testing.
Comments
"Conventions are implementation defined and would require patches to the compiler to add new ones."
Is the implementation of a Convention isolated enough that it would make sense to be extensible?
One thing I had in mind is something like Postgres. Some functions in Postgres are called in a specific way that converts arguments into an array first, and handles SQL NULL values. If I were to define this as a new Convention, it would inherit a lot from the "C" Convention, but would do some transformations first.
If it could handle a longjmp() as well, then the new Convention would also do whatever setup (manipulate some global variables and call setjmp()) so that the caller doesn't have to worry about the longjmp().
The challenge with handling longjmp() in rust is that you can't call setjmp() as a normal FFI function (because it can return twice, like fork(), which is not a normal control flow). Also, longjmp()ing into rust code is just not defined behavior, even if it "works" for now. I assume there are similar challenges in Ada.
Conventions are currently implemented in GNAT as a part of the parser/lexer just like any other syntax element, so it's not easily separated from the rest of the compiler. You could change that behavior, but that's not a small task. I don't think new calling conventions come along very often, so it seems unlikely to be worth the effort.
I don't know the details of the Postgres implementation, but this sounds to me like the sort of thing that would work well as a generic procedure.
GNAT doesn't use runtime FFI, it dynamically links libraries and maps them into memory the same as any other C program that uses gcc and binutils. I think this makes what you're describing possible, but I'm not familiar enough with how setjmp/longjmp interacts with the stack to be certain without doing more research and testing.