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

[Florian Klämpfl]

Am 19.08.2016 um 22:49 schrieb 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.

All? Or only the non-volatiles?

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

This is sligthly spread over the compiler, a starting point might be tcgmips.g_proc_entry in
compiler/mips/cgcpu.pas