Calling conventions

Hi,

in a computer science class we were discussing the RISC and used the MIPS ISA with the SPIM simulator for some practical labs. The SPIM simulator had the calling convention that registers $t0-$t9 were caller-saved while $s0-$s7 were callee-saved. So, here the division in these two classes of registers was static.

Another example are Infineon TriCore microcotrollers. They do not use caller-/callee-saved registers but with each call the upper context (consisting of some particular data and address registers) is automatically saved and restored with a return instruction. Thus, here an explicit division of registers across calls is not given.

My question is now what is the common practice for today's embedded system processors? Do they provide some unique memory subsystems for a fast context switching (like for the TriCore) or do they support the traditional way of a strict division of registers into callee-/caller-saved registers? If so, who defines which registers should be used for which purpose? Is there one particular calling convention for each processor people working in a shared project must strictly follow?

Regardas, Tim

Reply to
Tim Frink
Loading thread data ...

If the SPIM simulator is strictly an instruction set simulator then it shouldn't impose any particular use of the registers.

I have not worked on the higher end processors, but the smaller processors typically leave it up to the user. The 8051 has four banks of registers, but that mechanism is normally not used for function calls. It is used more for fast context switching for interrupts.

The person who writes the firmware. If you are writing standalone code in assembly language, you do. If you use a compiler, the compiler and library designers decide how to save context within the context of their compiler and library

Matching conventions. ;-) Someone usually specifies the context of a library or compiler which determines calling conventions. If you are really starting from scratch, it may make sense to adopt conventions from a compiler for a similar architecture.

--
Thad
Reply to
Thad Smith

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.