[fpc-devel] avr-port: register usage and calling convention?

Georg Hieber georg at ghgrp.com
Tue Mar 31 15:03:11 CEST 2015

Thanks, Florian.

I will dig a bit deeper and eventually file a report.


Am 31.03.2015 um 03:53 schrieb Florian Klämpfl:
> Am 31.03.2015 um 02:14 schrieb Georg Hieber:
>> Hi,
>> I am about to implement some rtl procedures in avr - assembler, and of course register usage and
>> calling conventions are important for that.
>> The fpc wiki says concerning avr, "It uses the GCC AVR tool chain and will be compatible with GCC
>> regarding calling conventions etc.". That would be passing arguments in  registers r25 - r8
>> downwards (first argument in r24, r25 if 16 byte, 2nd below that etc.). High bytes are in high and
>> low bytes in low register no.
>> Function results are returned in r22 - r25 (32byte), r24-r25 (16 byte). According to GCC
>> documentation, R0, R18-R27, R30, R31 are call used, R 2-R17, R28 and R29 are call saved. R1 has
>> always to be 0.
>> Actual code produced by the compiler looks different.  It is the same sequence of arguments (first
>> in highest registers, second below that ...), but the byte order is reversed, lowest byte in highest
>> register no.
>> After noting this discrepancy, I am of course unsure about the whole matter. Could somebody tell me
>> what convention is actually used by the compiler?
> It is supposed to the use gcc one. It is simply a bug if it differs.
>> A word to register R1: it shall be 0 at all times according to GCC specs. In some occasions, the
>> compiler uses this to set other registers to 0, by MOV reg, R0. On other occasions the compiler uses
>> the CLR Reg instruction (which is actually a pseudo opcode that translates to EOR reg, reg). On the
>> other hand, R0 and R1 are used by the MUL / MULS / MULSU instructions to return the multiplication
>> result. Forgetting to clear R0 again after a multiplication (i.e. in an assembler routine) will thus
>> lead to errors at some later time.
>> As long as the MOV is not used because it does not change any status flags, It might be a good idea
>> if the compiler always used the CLR instruction.
> I'll try to remember this :)
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

More information about the fpc-devel mailing list