Re: [PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
On Dec 11, 2007 8:43 AM, Joshua Isom [EMAIL PROTECTED] wrote: On Dec 10, 2007, at 10:59 AM, Klaas-Jan Stol wrote: In order to draw attention to this point, I changed the subject. Is there anybody who thinks the removal from PIR of $-less registers (absolute or PASM registers) should not be done? kjs 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. 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). I thought the parrot calling conventions were changed so, that it doesn't use these specific regs. (the old pcc said, that in I0, I1, I2 etc, special info about the invocation can be found, while the args were stored in specific regs.) I may be wrong. kjs
Re: [PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
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
Re: [PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
From: Allison Randal [EMAIL PROTECTED] Date: Tue, 11 Dec 2007 11:51:52 +0200 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.) The feature could continue to exist -- without the confusion -- by providing a way to disable register allocation altogether. The IMCC parseflags function already has code to select between the vanilla allocator and a graph-based allocator depending on optimization level; adding a null allocator ought to be useful for debugging. True? -- Bob Rogers http://rgrjr.dyndns.org/
[PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
In order to draw attention to this point, I changed the subject. On Dec 9, 2007 10:10 PM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan wrote: There is of course the option of taking the current behavior as correct, effectively forgetting about this piece of the specification. I can, however, imagine a situation in which someone would want to do manual register allocation (writing Parrot assembly) for certain cases. I'm not sure whether this manual allocation would be disregarded by IMCC which then does its own reg. allocation. That part of the spec/documentation was generally a caution against using the low-level registers, because they aren't guaranteed to do what you expect. Really, I'd be okay with disallowing the $-less register variables in PIR. Allison Is there anybody who thinks the removal from PIR of $-less registers (absolute or PASM registers) should not be done? kjs
Re: [PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
On Dec 10, 2007, at 10:59 AM, Klaas-Jan Stol wrote: In order to draw attention to this point, I changed the subject. Is there anybody who thinks the removal from PIR of $-less registers (absolute or PASM registers) should not be done? kjs 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. 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).
