By: rwessel (rwessel.delete@this.yahoo.com), September 22, 2022 8:50 am
Room: Moderated Discussions
Anon (no.delete@this.spam.com) on September 22, 2022 6:25 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on September 22, 2022 6:13 am wrote:
> > If you're suggesting that register usage could be added to the ABI in some fashion, no that's not usually
> > done, and I'm not sure how it really could be, the ABIs are often used to define interfaces where the two
> > sides (caller and callee) are built at different time. The first thought would be to add such information
> > to the name decoration, but that happens at the wrong time, with incomplete information, for something like
> > callers in C++. JITs, of course, could optimize across such boundaries, at least in some cases.
>
> Yep, that's my suggestion, the problem about thinking of C/C++ is that those languages only know the function
> name, they don't really include many information about the function (well, function names aren't an efficient
> way to encode metadata, name decoration is just an ugly quirk), JITs usually include much more information,
> a binary (non-JIT) could include more information, if C legacy isn't a problem.
Even languages that implement a proper module concept have an issue if two bits can be built at different times, which is not infrequently the case where a system ABI applies. The first time a particular build of a shared library and an executable may meet is when they are run together on some system, far removed from either build environment. A late compilation (specialization before first execution) or a JIT can fix that.
> rwessel (rwessel.delete@this.yahoo.com) on September 22, 2022 6:13 am wrote:
> > If you're suggesting that register usage could be added to the ABI in some fashion, no that's not usually
> > done, and I'm not sure how it really could be, the ABIs are often used to define interfaces where the two
> > sides (caller and callee) are built at different time. The first thought would be to add such information
> > to the name decoration, but that happens at the wrong time, with incomplete information, for something like
> > callers in C++. JITs, of course, could optimize across such boundaries, at least in some cases.
>
> Yep, that's my suggestion, the problem about thinking of C/C++ is that those languages only know the function
> name, they don't really include many information about the function (well, function names aren't an efficient
> way to encode metadata, name decoration is just an ugly quirk), JITs usually include much more information,
> a binary (non-JIT) could include more information, if C legacy isn't a problem.
Even languages that implement a proper module concept have an issue if two bits can be built at different times, which is not infrequently the case where a system ABI applies. The first time a particular build of a shared library and an executable may meet is when they are run together on some system, far removed from either build environment. A late compilation (specialization before first execution) or a JIT can fix that.