[fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?

[Michael Ring]

Am 19.08.16 um 14:49 schrieb Jonas Maebe:
>
> Michael Ring wrote on Sat, 13 Aug 2016:
>
>> I am trying to bring interrupt handling routine size down (and speed 
>> up) for mipsel-embedded target.
>>
>> I need to use inline assembler routines like this one
>>
>> procedure TSystemCore.setCoreTimerComp(value : longWord); assembler; 
>> nostackframe;
>> asm
>>   mtc0 $a1,$11,0
>> end ['a1'];
>
> Mentioning changed registers at the end of a pure assembler routine 
> has no effect. The compiler normally prints a warning about this. The 
> set of changed registers by a routine always only depends on its 
> calling convention. On most platforms we only support the official 
> ABI's calling convention, which is also the default.
>

I also tried also something like this:

procedure TSystemCore.setCoreTimerComp(value : longWord);
begin
   asm
     mtc0 $a1,$11,0
   end ['a1'];
end;

with same result, all registers are saved. intead of only a few.

>> inside of the interrupt handler, but as soon as I include the call to 
>> this procedure the number of registers that get saved explodes. When 
>> I only need to modify some peripheral I usually get away with only 
>> $v0 and $v1 registers getting saved, but with asm routine included 
>> all registers get saved.
>
> If the ABI default calling convention states that a routine may change 
> all registers, that is to be expected.
>
>> Same is true if I put the asm block directly inside of the interrupt 
>> handler.
>
> In that case, the list of changed registers should be taken into 
> account. OTOH, using an inline assembler blocks disables the use the 
> use of register variables for that routine by the compiler, but that 
> should result in less registers getting saved rather than more.

Do you remember where this is coded or for what I should search in the 
fpc sourcecode? Then I can try to find out what is going on in the mips 
case.

Thank you,

Michael

>
>
> Jonas
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel