Tock 2.0 First Steps
===

###### tags: `Meeting` `Tock 2.0`

:::info
- **Date:** July 7th, 2020 12:00PM (EDT)
- **Agenda**
1.
- **Participants:**
- Amit (AL)
- Johnathan Van Why (JVW)
- Jon Flatley (JF)
- Guillaume Endignoux (GE)
- Phil Levis (PL)
- Leon Schuermann (LS)
- **Host:** AL

:::

## Notes
<!-- Other important details discussed during the meeting can be entered here. -->

I’ve been looking into this. A useful reference is the syscall(2) man page, which outlines, for every Linux architecture, which registers are used for what.

The general approach is that return values follow the standard C ABI for that architecture. Arguments are different, because Linux sys calls started assuming 6 from x86 so it spread.

My read is the issue is whether the return values map to the calling language. E.g., what use is returning 4 registers if the caller can’t use them? If there is metadata/information that the kernel wants to pass back but which a syscall caller won’t consume (e.g., suppose you received a timestamp for every system call), then it might make sense to put this into r2/r3.

Let’s take an example where we might want 3 registers: requesting a 64-bit timestamp with the possibility of an error (fail to get timestamp). How would you map these 3 register into a C call? The C ARM EABI is pretty clear (e.g., for ARM) that you don’t do this. *However*, EABI does say that if the return value is a containerized vector of 128 bits then it can be returned in r0-r3. But we aren’t using containerized vectors.

What this suggests to me is we should go with r0/r1 (a0/a1 for RISC-V) and the return value being a 64-bit fundamental type, which is then packed/unpacked appropriately.