2

ABI (Application binary interface) defines things like caller and callee saved registers, stack use, register use, end-of-routine stack pop etc.

Is ABI only an agreement between compilers and other software to make sure they don't overwrite each other, or is it also governed by the hardware itself? i.e if we all agree on using caller saved registers as callee saved registers things will continue to function normally as the hardware doesn't really care?

Dave
  • 21
  • 1
  • https://stackoverflow.com/q/2171177 – Robert Harvey May 27 '21 at 19:57
  • [An ABI defines how data structures or computational routines are accessed in machine code, which is a low-level, hardware-dependent format. In contrast, an API defines this access in source code, which is a relatively high-level, hardware-independent, often human-readable format.](https://en.wikipedia.org/wiki/Application_binary_interface) – Robert Harvey May 27 '21 at 20:01
  • Thanks, but i'm asking if its enforced by the hardware or not (i'm sure it's not). – Dave May 27 '21 at 20:20
  • What do you mean by "enforced?" You can break the "rules" of an ABI (or API) at will. The results may not be what you expect, however. – Robert Harvey May 27 '21 at 20:26
  • i'm saying when a register is marked a "callee saved" register, is the CPU hard coded somehow to see it as a "callee saved" register, or to the CPU its just another register and it doesn't care. the "callee saved" thing is a software agreement between people, nothing more. – Dave May 27 '21 at 20:30
  • I believe that is merely a mutually agreed-upon convention. See https://stackoverflow.com/q/9268586. However, these conventions are apparently documented in the ABI; see https://stackoverflow.com/a/56178078. It's a pretty safe bet that the hardware *does not* enforce these conventions; rather, the ABI attempts to ensure good behavior amongst developers. Registers are essentially global storage locations, available to anyone at any time in any part of the program. – Robert Harvey May 27 '21 at 21:04
  • Why not both? :D – Filip Milovanović May 27 '21 at 23:21
  • 1
    The most obvious example is that you can't have either caller-saved registers or callee-saved registers if the hardware has no registers. – Jörg W Mittag May 28 '21 at 07:03
  • @Dave It is just another register. – user253751 Sep 10 '21 at 16:43

3 Answers3

3

It can be both. An ABI is a convention, and there might exist several such conventions for a given hardware architecture (see https://en.m.wikipedia.org/wiki/X86_calling_conventions) but in general they are at least partly directed by the architecture features.

For example, a processor architecture may define a standard return address register which is set by call instructions but at the same time allow other registers to be used for indirect calls, so a compiler could potentially define a different ABI but would go "against the grain" in doing so.

Hans-Martin Mosner
  • 14,638
  • 1
  • 27
  • 35
3

ABIs are a convention. There can be multiple conventions in use on a single platform - a classic example is early Windows using "Pascal" calling convention despite many of the parts being written in C.

is the CPU hard coded somehow to see it as a "callee saved" register

The only thing that matters here is "what does the CPU actually do when you call/return". This is nearly always that it saves/restores the program counter and nothing else.

(Some architectures really do "caller save" in hardware, but this isn't very widespread)

If you overwrite a callee-saved register, nothing happens and the CPU neither knows nor cares .. until you return. At which point it depends on whether the calling function actually uses the value you've overwritten. You might get away with it, you might crash the program, you might just corrupt the results.

pjc50
  • 10,595
  • 1
  • 26
  • 29
2

A Little of This and a Little of That

For example how do you arrange the arguments for a function on a stack?

  • C-Style? The first argument is pushed last onto the stack
  • Pascal Style? The first argument is pushed first onto the stack

Both have upsides, and both have downsides. But neither is enforced by the hardware.

On the other hand datatype alignment is influenced by the hardware. The hardware is usually optimised to store specific types of operand at specific byte alignment offsets. Some platforms do support loading unaligned data, but there is usually an associated performance penalty. As such these alignments are somewhat/fully specified by the hardware.

Oddly enough some of the ABI isn't specified by hardware, but by platform. After all, to do just about anything on a computer these days, you must interact with the Operating System, and that OS has specific expectations about how it is to be interacted with.

Kain0_0
  • 15,888
  • 16
  • 37