cvs commit: parrot/docs jit.pod
Nicholas Clark
> +B<MAP[n]>
> +
> +The I<n>th integer or floating processor register, mapped in this section.
> +
> +Note: The register with the physical number zero can not be mapped.
> +
> +=begin unimp
> +
Why can't it be mapped? Fundamental implementation constraints (using
zero to flag something else?) This will impact performance, although
whether it's not actually measurable, slight, or moderate, I don't know.
["patches welcome"?]
Nicholas Clark
Nicholas Clark
> Either we fix this, or the registers have to be renumbered, so that reg
> #0 is not used. The emit_code for registers could take care of this.
That's a crafty trick. nothing wrong with that :-)
> Currently no architecture has this problem, register #0 is used as
> scratch register.
>
> i386 uses register numbers 1 higher then actual, though EAX nether gets
> mapped.
>
>
> > ["patches welcome"?]
>
>
> Always, but as currently no architecture is concerned ...
Valid point.
But I was envisaging for ARM that r12 or r14 ought to be the scratch
register. The way the ABI works, with r12 trashed on function call entry,
but r0 used to return values from functions means that r12 is available
within an op, while mapping r0 to a parrot register for the first JITted
op after an external call could save 1 register move.
Nicholas Clark
Leopold Toetsch
> On Tue, Nov 26, 2002 at 09:55:00AM -0000, Leopold Toetsch wrote:
>
>
>> +B<MAP[n]>
>> +
>> +The I<n>th integer or floating processor register, mapped in this section.
>> +
>> +Note: The register with the physical number zero can not be mapped.
>> +
>> +=begin unimp
>> +
>>
>
> Why can't it be mapped? Fundamental implementation constraints (using
> zero to flag something else?)
Yep. The test for a mapped register:
if (MAP[1]) is the problem: this translate to
jit_info->optimizer->map_branch[jit_info->op_i + 1]
where map_branch is the {int,float}val_map at the end of jit_emit.h i.e.
the register list.
> ... This will impact performance, although
> whether it's not actually measurable, slight, or moderate, I don't know.
Either we fix this, or the registers have to be renumbered, so that reg
#0 is not used. The emit_code for registers could take care of this.
Currently no architecture has this problem, register #0 is used as
scratch register.
i386 uses register numbers 1 higher then actual, though EAX nether gets
mapped.
> ["patches welcome"?]
Always, but as currently no architecture is concerned ...
> Nicholas Clark
leo
Leopold Toetsch
>
> But I was envisaging for ARM that r12 or r14 ought to be the scratch
> register. The way the ABI works, with r12 trashed on function call entry,
> but r0 used to return values from functions means that r12 is available
> within an op, while mapping r0 to a parrot register for the first JITted
> op after an external call could save 1 register move.
Don't do that ;-)
1) jit/i386 already has JITted native vtable calls with return values.
So mapping a register, which returns values from functions is not a good
idea because:
2) Next optimizations will avoid register load/store, when a register is
preserved, register allocation will be more long ranged (i.e. past
external calls too). For this, we need some notion for preserved
registers, e.g. #define PRESERVED_REGS 3 (first 3 regs are callee saved).
The one reg/reg move is by far more inexpensive then a reload from memory.
Here is a snippet of my proposal I sent to Daniel:
<cite>
In the meanwhile, I'll have some ideas for jit.c, which I could start
coding:
- move Parrot_jit_save/_load_registers to jit.c
- check usage of all registers -> reg_usage[4][NUM_REGISTERS] ...
- check usage in non JITted sections too
- optimize register allocation:
* when register usage of next section doesn't collide, keep usage
- optimize load and store
* store always before non jitted section (exceptions)
* load only differing registers
BTW, is it an improvement to allocate a register, when the use count==1?
Changes beyond this: allocate P (and S) registers too: the JITed vtable
calls could benefit from this. If there are too many registers to
allocate (damned i386) I would weight the allocation like e.g. 10:2:1
for I:P:S, so if a P parrot register is heavily used, it would get a
processor register.
</cite>
First is done.
Second is in work currently.
Last is done (for RHS use_count == 1).
> Nicholas Clark
leo