imcc and pdd03
Leopold Toetsch
assignment, I fear that the described calling conventions can't be done.
The pod states:
I5 through I31
The first 26 integer parameters.
S5 through S31
The first 27 string parameters.
N5 through N31
The first 27 numeric parameters.
P5 through P31
The first 27 PMC parameters.
Ignoring a slight off by one error ;), where should these registers come
from? For sure, some are temp vars, and when there are 27 registers of
one kind (or more) necessary, to feed a sub, there are probably a lot of
temps active too. Just to do the assignments to get the sub params into
the correct register, would need a lot of spilling regs in and out.
This could of course somehow optimized, so that the destination
registers is already the register of the temp, but what if there are 2
such subs, which just one additional parameter at the end, which would
shift all others and makes such an optimization impractical.
Next problem is, imcc needs one P-Reg (currently P31) for a spill array,
which for sure is necessary, when there are +27 P regs to be passed to a
sub.
So my proposal is, to reduce the amount of parameters passed in
registers to some lower value, to take some pressure off the register
allocator.
x5 through x15
would be still a lot of params.
leo
Dan Sugalski
>So my proposal is, to reduce the amount of parameters passed in
>registers to some lower value, to take some pressure off the
>register allocator.
>
> x5 through x15
>
>would be still a lot of params.
Okay, done! Checkin to follow soon.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> At 6:03 PM +0100 3/12/03, Leopold Toetsch wrote:
>
>> So my proposal is, to reduce the amount of parameters passed in
>> registers
>
> Okay, done! Checkin to follow soon.
Wow, really fast, thanks.
Still remaing - probably /me not understanding the following:
The following registers, with the exception of P
registers, are used only when calling a subroutine for
which there is a compile-time prototype. The first 27 PMC
parameters may be passed in registers P5 through P31.
...
P5 through P15
The first 11 PMC parameters.
Could you please tighten this a little bit more:
- a compile-time prototype is the signature, I presume?
- when do we have one, when not?
- how are parameters now passed in either case?
TIA,
leo
Dan Sugalski
Will do. Should be in soon.
Dan Sugalski
>Dan Sugalski wrote:
>
>>At 6:03 PM +0100 3/12/03, Leopold Toetsch wrote:
>>
>>So my proposal is, to reduce the amount of parameters passed in registers
>>
>>Okay, done! Checkin to follow soon.
>
>
>Wow, really fast, thanks.
>
>Still remaing - probably /me not understanding the following:
>
> The following registers, with the exception of P
> registers, are used only when calling a subroutine for
> which there is a compile-time prototype. The first 27 PMC
> parameters may be passed in registers P5 through P31.
D'oh! Fixed.
> P5 through P15
> The first 11 PMC parameters.
>
>Could you please tighten this a little bit more:
>- a compile-time prototype is the signature, I presume?
Yes. The whole intent of this was to allow for subs whose parameters
weren't PMCs. Say, for example, you had a sub who's signature was:
foo(int, int, float, string)
If we knew that at compile time we could put the first two parameters
in I5 and I6, the float param in N5, and the string parameter in S5.
If we *didn't* know the signature, we'd put the parameters in P5-P8.
I'd planned on having a way to let the sub know which way we were
calling it (with or without signature) so it'd know where to get its
parameters.
I'd assumed that the sub would take the "no prototype" case and move
the params to the right places based on the sub prototype, as I
figured the sub being called would know its own prototype.
The sub calling PDD is a little sloppier than I'd like. Once I get
the object stuff nailed down a little better, I'd like to readdress
it some. Mainly to skip passing parameters on the stack and using an
array PMC to hold the overflow (both on input and output), and better
return value specifications.
Objects first, though--PDD 15 beckons. *Then* you and I can work out
the fuzzy bits so it both makes sense and IMCC can work with it well.
Leopold Toetsch
[ lotta explanation skipped ]
> Objects first, though--PDD 15 beckons. *Then* you and I can work out the
> fuzzy bits so it both makes sense and IMCC can work with it well.
Thanks for the details. And as objects probably will shed some more
light on calling conventions, I'm fine with postponing them.
leo