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

[Sergei Gorelkin]

21.08.2016 12:06, Karoly Balogh (Charlie/SGR) пишет:
> Hi,
>
> On Sun, 21 Aug 2016, Michael Ring wrote:
>
>> So unless there is a way to find out which registers get used by a procedure
>> the only thing I can do to make interrupt routines as lean as possible is to
>> not use procedures in them if possible.
>
> There is a way, of course. Seems like the MIPS CG was never updated to
> depend on cgobj.g_save_registers/cgobj.g_restore_registers (or implement
> these on its own), which takes into account which registers were used in
> the procedure, and only saves those. See g_save/restore_registers
> implementation in cgobj.pas for an inspiration how it should be done. The
> m68k CG also reimplements these methods with some CPU-specific extensions.
>
> It seems to use the old-style approach of just always saving all volatile
> registers, and do everything on its own in g_proc_entry/exit which is the
> old way (and also still used in some other CGs).
>
> Not sure why it was never updated tho' for MIPS, I don't know anything
> about the MIPS CG, and very little about the architecture itself. But it
> sounds like this definitely the improvement you want.
>


It is actually the opposite way around. g_save_registers/g_restore_registers methods
are only used for first implemented targets (i386 and maybe m68k). All newer targets are written 
without calling them, since they are completely inappropriate to implement stack frame optimizations 
or push/pop-alike instructions for register saving.

MIPS codegenerator does check which registers are actually used. The issue is, a procedure with 
'interrupt' modifier must not modify any registers at all because it can be called asynchronously. 
As soon as an 'interrupt' procedure calls another (regular) procedure, the callee may modify any 
registers from volatile list, and the caller has no way to know which ones. Therefore, it has no 
other option than to save/restore all volatile registers.

Regards,
Sergei