J
Jerry Coffin
[ ... ]
There was (at least) one attempt at defining something on the order of a
cross-platform ABI. Back in the 1980's (or so) the DCE worked on a
standard for executables that was intended to allow you to compile an
executable once, and run it on any conforming implementation of UNIX.
IIRC, there were even a few working implementations, but it never really
caught on.
To a degree, almost anything like this requires a fair amount of
intelligence in the target to convert from the generic ABI to something
that's understood directly by the target hardware. You can vary _when_
you do that conversion, so that (for example) the conversion is done
when the program is installed, or when it's loaded, or while it's
running -- but some sort of conversion is (essentially) always needed.
If you want to avoid that conversion completely, you're stuck with
defining the ABI to suit the target hardware. In this case, you're going
to end up with differences across different hardware. Even on the same
hardware, there are enough differences in how different OSes work that
the vendor of each OS typically attempts to optimize their calling
conventions and such based on their own usage.
Just for example, one OS might use a small number of function calls with
many parameters to carry out a specific operation. A second OS might use
a larger number of function calls, with fewer parameters apiece to carry
out the same operation.
The two are likely to favor different calling conventions. There may be
less obvious effects as well though -- for example, the second is more
likely to favor minimizing the state that needs to be saved during a
switch from user to supervisor mode (or vice versa). This, in turn, will
affect things like how parameters are passed, especially during a mode
switch (e.g. loading data into registers vs. storing in memory and
passing a pointer to the parameter block).
There was (at least) one attempt at defining something on the order of a
cross-platform ABI. Back in the 1980's (or so) the DCE worked on a
standard for executables that was intended to allow you to compile an
executable once, and run it on any conforming implementation of UNIX.
IIRC, there were even a few working implementations, but it never really
caught on.
To a degree, almost anything like this requires a fair amount of
intelligence in the target to convert from the generic ABI to something
that's understood directly by the target hardware. You can vary _when_
you do that conversion, so that (for example) the conversion is done
when the program is installed, or when it's loaded, or while it's
running -- but some sort of conversion is (essentially) always needed.
If you want to avoid that conversion completely, you're stuck with
defining the ABI to suit the target hardware. In this case, you're going
to end up with differences across different hardware. Even on the same
hardware, there are enough differences in how different OSes work that
the vendor of each OS typically attempts to optimize their calling
conventions and such based on their own usage.
Just for example, one OS might use a small number of function calls with
many parameters to carry out a specific operation. A second OS might use
a larger number of function calls, with fewer parameters apiece to carry
out the same operation.
The two are likely to favor different calling conventions. There may be
less obvious effects as well though -- for example, the second is more
likely to favor minimizing the state that needs to be saved during a
switch from user to supervisor mode (or vice versa). This, in turn, will
affect things like how parameters are passed, especially during a mode
switch (e.g. loading data into registers vs. storing in memory and
passing a pointer to the parameter block).