[RFC] Linux system call builtins

[Matheus Afonso Martins Moreira <matheus.a.m.moreira@gmail.com>]

> As noted by J. Wakely, you don't need to have one variant
> for each number of arguments.

Yes, he is right about that. I have already deleted
all the variants from my code since the variadic
builtin will be able to generate optimal code,
unlike a variadic C function.

> I assume you're talking about the interface
> which is often abstracted by functions such as
> the following which are often found in libcs or
> freestanding libraries.

> long linux_system_call_1(long number, long _1)

Yes, that's exactly what I have in mind.
My goal is to implement those functions
inside the compiler itself as builtins.

> I think that at least on sysv x86_64, syscalls have
> the same calling conventions as regular functions.
However, the
function descriptor is not an address (or a symbol reference) but a
number.

They are similar but not equal.

x86_64 function calling convention passes the first 6 arguments
in the following registers: rdi, rsi, rdx, rcx, r8, r9.
x86_64 system call calling convention passes only 6 arguments
in the following registers: rdi, rsi, rdx, r10, r8, r9.

System calls use r10 instead of rcx
and don't support more than 6 arguments.

> At least, it would be nice if not all freestanding libraries
had to reimplement those syscalls stubs.

Completely agree!

> I think you could have a look at the function 'expand_call'
> in calls.cc to see how regular calls are expanded to RTL

Thanks for the pointer!! I had been looking
in the gcc/config/ directory for platform specific
code that implemented calling conventions.
Somehow that calls.cc file slipped past my attention.

My thinking is that I need to have the compiler
evaluate the input expressions and place the
results in specific registers, while also ensuring
all the input expressions are register sized and
emitting type errors in case they are not.
I looked for some kind of "register" type
but didn't find anything. So I used long int,
just like the libraries do.

Thanks,
    Matheus