Cheat Sheet about CPU registers and calling convention

645 views
Skip to first unread message

Viller Hsiao

unread,
Mar 10, 2017, 12:02:48 PM3/10/17
to RISC-V SW Dev
Hi all,

To get familiar with CPU architectures, I made a cheat sheet about the register map of RISC-V/ARM/MIPS/x86. The URL is
Hope it's helpful.

Regards,
Viller

Bruce Hoult

unread,
Mar 10, 2017, 1:54:30 PM3/10/17
to Viller Hsiao, RISC-V SW Dev
This could be useful.

Should include the register numbers for x86 named registers.

The definition of "scratch registers" isn't consistent, as you included argument registers for some but not others (e.g. RISC-V)

The definition of "Intra-procedure-call scratch register" is not consistent, as it doesn't include e.g. RISC-V t0-t6.

I think you only need one of these categories, as I'm not aware of any ABI in which a called function is not allowed to destroy argument registers.


To me, "scratch register" means anything a function is allowed to destroy. There ar two kinds: registers which might hold an argument (and thus can not be touched by linkage code between the calling function and the called function), and registers which can't hold an argument ("Intra-procedure-call scratch register") and thus can be freely destroyed by code between the calling function and the called function, as well as by the called function.


--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/0396106f-9929-4d9c-a858-195fe94f8036%40groups.riscv.org.

Michael Clark

unread,
Mar 10, 2017, 6:27:07 PM3/10/17
to Viller Hsiao, Bruce Hoult, RISC-V SW Dev
Yes. It’s quite useful.

There is the question as to whether there needs to be RV32 and RV64 columns however the register assignments are common to both so it is not really necessary.

There is also RV32E to consider.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

Benjamin Scherrey

unread,
Mar 10, 2017, 10:30:06 PM3/10/17
to Viller Hsiao, RISC-V SW Dev
Quite useful. Might want to include bit sizes as well. 

--

Viller Hsiao

unread,
Mar 11, 2017, 4:42:20 AM3/11/17
to RISC-V SW Dev, ville...@gmail.com, br...@hoult.org








Bruce Hoult於 2017年3月11日星期六 UTC+8上午2時54分30秒寫道:
This could be useful.

Should include the register numbers for x86 named registers.
This is done.
 
The definition of "scratch registers" isn't consistent, as you included argument registers for some but not others (e.g. RISC-V)

The definition of "Intra-procedure-call scratch register" is not consistent, as it doesn't include e.g. RISC-V t0-t6.

I think you only need one of these categories, as I'm not aware of any ABI in which a called function is not allowed to destroy argument registers.


To me, "scratch register" means anything a function is allowed to destroy. There ar two kinds: registers which might hold an argument (and thus can not be touched by linkage code between the calling function and the called function), and registers which can't hold an argument ("Intra-procedure-call scratch register") and thus can be freely destroyed by code between the calling function and the called function, as well as by the called function.


I think you are right, it is inconsistent in scratch registers fields. Arguments are removed from there to keep the original "scratch register" field smaller. "scratch registers" field is renamed as "other scratch registers (besides argument)" to make them clear.

Intra-procedure-call scratch registers are used by call veneers and PLT code in ARM/ARM64. Therefore I put them in an independent row. The row for architecture-specific purpose are marked as different color in the description column.

Thanks for your suggestion.

Viller Hsiao

unread,
Mar 11, 2017, 4:44:14 AM3/11/17
to RISC-V SW Dev, ville...@gmail.com, br...@hoult.org
Let me check that. Will update later.

michaeljclark於 2017年3月11日星期六 UTC+8上午7時27分07秒寫道:
Yes. It’s quite useful.

There is the question as to whether there needs to be RV32 and RV64 columns however the register assignments are common to both so it is not really necessary.

There is also RV32E to consider.

On 11 Mar 2017, at 7:54 AM, Bruce Hoult <br...@hoult.org> wrote:

This could be useful.

Should include the register numbers for x86 named registers.

The definition of "scratch registers" isn't consistent, as you included argument registers for some but not others (e.g. RISC-V)

The definition of "Intra-procedure-call scratch register" is not consistent, as it doesn't include e.g. RISC-V t0-t6.

I think you only need one of these categories, as I'm not aware of any ABI in which a called function is not allowed to destroy argument registers.


To me, "scratch register" means anything a function is allowed to destroy. There ar two kinds: registers which might hold an argument (and thus can not be touched by linkage code between the calling function and the called function), and registers which can't hold an argument ("Intra-procedure-call scratch register") and thus can be freely destroyed by code between the calling function and the called function, as well as by the called function.

On Fri, Mar 10, 2017 at 8:02 PM, Viller Hsiao <ville...@gmail.com> wrote:
Hi all,

To get familiar with CPU architectures, I made a cheat sheet about the register map of RISC-V/ARM/MIPS/x86. The URL is
Hope it's helpful.

Regards,
Viller

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/0396106f-9929-4d9c-a858-195fe94f8036%40groups.riscv.org.

Viller Hsiao

unread,
Mar 12, 2017, 1:47:30 AM3/12/17
to RISC-V SW Dev, ville...@gmail.com, br...@hoult.org




Viller Hsiao於 2017年3月11日星期六 UTC+8下午5時42分20秒寫道:
Hi Bruce,

I can't find last comment so reply here.
I have reviewed scratch fields as well as preserved registers again and agree that scratch register for dynamic linking should not be architecture-specific. After thinking again, it might be easier to collect all scratch ones together. 

Viller

Reply all
Reply to author
Forward
0 new messages