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

Florian Klämpfl florian at freepascal.org
Fri Aug 19 23:01:31 CEST 2016

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

More information about the fpc-devel mailing list