On Dec 11, 2007 8:43 AM, Joshua Isom <[EMAIL PROTECTED]
Parrot provides a calling convention, but does not, that I know of,
mandate that calling convention. In any computer, there are multiple
calling conventions used(often leading to a lack of interoperability,
but nevertheless present). The system itself uses specific registers.
Mixing absolute and relative registers in PIR does cause problems, but
a program that solely used absolute registers and its own calling
convention shouldn't be necessarily forbidden.
The thing is, PIR doesn't respect the register numbers anyway (even in
the so-called "absolute" registers). So P33 in the PIR source may
compile down to P0, and P0 in the PIR source may compile down to P15.
(Try "-o file.pasm" on any random PIR file that uses "absolute" registers.)
We're not eliminating a feature, we're just making it clear that the
feature doesn't exist. (And eliminating the confusion of people
expecting it to exist.)
Currently parrot has
several ops that assist a different language/calling convention, such
as bsr, and others of it's ilk. Mixing those ops and the "standard"
calling convention ops together will probably cause massive problems,
but they still exist(even if they're there more because they were long
ago rather than need to be).
In PIR, 'bsr' only works within a compilation unit (that is, within a
subroutine). It doesn't work between compilation units. So, you really
have to fall back to PASM to fully use those features anyway.
Klaas-Jan Stol wrote:
I thought the parrot calling conventions were changed so, that it
doesn't use these specific regs.
Yes, the calling conventions now use 'get_params' and 'get_results' to
specify where the arguments/return values should be stored, instead of
using specific registers.
Allison
