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

Karoly Balogh (Charlie/SGR) charlie at scenergy.dfmk.hu
Sun Aug 21 12:25:50 CEST 2016


On Sun, 21 Aug 2016, Sergei Gorelkin wrote:

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

Well, they still have stubs in the HLCG, which is why I thought it must be
newer than just dumping everything in g_proc_entry. Actually, I
implemented them quite recently for 68k, and they're still routed in live
code in psub.pas.

However, since historically I missed the large compiler refactor in the
mid-'00s, I believe you. Anyway...

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

Well, one possible optimization would be to only save all volatiles if the
interrupt routine actually calls another function. Otherwise only save the
ones used by the current proc. This would allow some very small and very
fast interrupt functions, right? I'm not sure though if there's an easy
way to determine if there is a function call inside the function I'm
generating code for.

Maybe at the point of generating a function call, if the current proc is
an interrupt, mark all volatiles as used somehow?


More information about the fpc-devel mailing list