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

[Jonas Maebe]

On 19/08/16 22:49, Michael Ring wrote:
>
> 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.

It is not clear what you mean by this. In your original message, you 
said that all registers were saved "as soon as I include the call to 
this procedure". As explained, the registers that are saved when calling 
a routine only depend on what the ABI says are volatile/callee-saved 
registers. Which registers are actually used by the called routine have 
no influence at all.

>>> 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.

It's the last part of the _asm_statement function in compiler/pstatemnt.pas

FWIW, tcpuparamanager.get_volatile_registers_int() in mips/cpupara.pas 
suggests that all integer registers except for R16-R23 are volatile, so 
no matter what you do, if any of those registers contains a value that 
is still needed after a call, they will be saved and restored.


Jonas