public inbox for [email protected]
 help / color / mirror / Atom feed
From: Willy Tarreau <[email protected]>
To: Ammar Faizi <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>,
	Alviro Iskandar Setiawan <[email protected]>,
	Nugraha <[email protected]>,
	Linux Kernel Mailing List <[email protected]>,
	GNU/Weeb Mailing List <[email protected]>,
	David Laight <[email protected]>
Subject: Re: [PATCH v1 04/11] tools/nolibc: x86-64: Use appropriate register constraints if exist
Date: Thu, 24 Mar 2022 08:57:28 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Thu, Mar 24, 2022 at 02:30:32PM +0700, Ammar Faizi wrote:
> Use appropriate register constraints if exist. Don't use register
> variables for all inputs.
> 
> Register variables with "r" constraint should be used when we need to
> pass data through a specific register to extended inline assembly that
> doesn't have a specific register constraint associated with it (anything
> outside %rax, %rbx, %rcx, %rdx, %rsi, %rdi).
> 
> It also simplifies the macro definition.

I'm a bit bothered by this one because I went the exact opposite route
in the early design precisely because I found that the current one was
simpler. E.g, I personally find this one:

> -#define my_syscall6(num, arg1, arg2, arg3, arg4, arg5, arg6)                  \
> -({                                                                            \
> -	long _ret;                                                            \
> -	register long _num  __asm__("rax") = (num);                           \
> -	register long _arg1 __asm__("rdi") = (long)(arg1);                    \
> -	register long _arg2 __asm__("rsi") = (long)(arg2);                    \
> -	register long _arg3 __asm__("rdx") = (long)(arg3);                    \
> -	register long _arg4 __asm__("r10") = (long)(arg4);                    \
> -	register long _arg5 __asm__("r8")  = (long)(arg5);                    \
> -	register long _arg6 __asm__("r9")  = (long)(arg6);                    \
> -	                                                                      \
> -	__asm__ volatile (                                                    \
> -		"syscall\n"                                                   \
> -		: "=a"(_ret)                                                  \
> -		: "r"(_arg1), "r"(_arg2), "r"(_arg3), "r"(_arg4), "r"(_arg5), \
> -		  "r"(_arg6), "0"(_num)                                       \
> -		: "rcx", "r11", "memory", "cc"                                \
> -	);                                                                    \
> -	_ret;                                                                 \

Easier to grasp than this one:

> +#define my_syscall6(num, arg1, arg2, arg3, arg4, arg5, arg6)	\
> +({								\
> +	long _ret = (num);					\
> +	register long _arg4 __asm__("r10") = (long)(arg4);	\
> +	register long _arg5 __asm__("r8")  = (long)(arg5);	\
> +	register long _arg6 __asm__("r9")  = (long)(arg6);	\
> +	__asm__ volatile (					\
> +		"syscall\n"					\
> +		: "+a"(_ret)	/* %rax */			\
> +		: "D"(arg1),	/* %rdi */			\
> +		  "S"(arg2),	/* %rsi */			\
> +		  "d"(arg3),	/* %rdx */			\
> +		  "r"(_arg4),	/* %r10 */			\
> +		  "r"(_arg5),	/* %r8  */			\
> +		  "r"(_arg6)	/* %r9  */			\
> +		: "rcx", "r11", "memory", "cc"			\
> +	);							\
> +	_ret;							\
>  })

where only half of the registers are described at one place and the
other half is described in comments at another place. But admittedly
it's a matter of taste. However the same approach was adopted for all
other archs (arm, aarch64, mips, riscv) and I tend to find it easier
to compare the ABI between architectures when all registers are
described at once than when two of them (i386 and x86_64) make an
exception.

I'd say that if there is any technical benefit in doing this (occasional
code improvement or better support for older or exotic compilers), I'd say
"ok go for it", but if it's only a matter of taste, I'm not convinced at
all and am rather seeing this as a regression. Now if there's rough
consensus around this approach I'll abide, but then I'd request that other
archs are adapted as well so that we don't keep a different approach only
for these two ones.

Thanks,
Willy

  reply	other threads:[~2022-03-24  7:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-24  7:30 [PATCH v1 00/11] Add dynamic memory allocator support for nolibc Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 01/11] tools/nolibc: x86-64: Update System V ABI document link Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 02/11] tools/nolibc: Remove .global _start from the entry point code Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 03/11] tools/nolibc: Replace `asm` with `__asm__` Ammar Faizi
2022-03-24  7:41   ` Willy Tarreau
2022-03-24  9:03     ` Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 04/11] tools/nolibc: x86-64: Use appropriate register constraints if exist Ammar Faizi
2022-03-24  7:57   ` Willy Tarreau [this message]
2022-03-24  8:33     ` Alviro Iskandar Setiawan
2022-03-24  9:00       ` Ammar Faizi
2022-03-24 15:42       ` Willy Tarreau
2022-03-24  7:30 ` [PATCH v1 05/11] tools/nolibc: i386: " Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 06/11] tools/nolibc: i386: Implement syscall with 6 arguments Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 07/11] tools/nolibc/sys: Implement `mmap()` and `munmap()` Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 08/11] tools/nolibc/types: Implement `offsetof()` and `container_of()` macro Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 09/11] tools/nolibc/stdlib: Implement `malloc()`, `calloc()`, `realloc()` and `free()` Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 10/11] tools/nolibc/string: Implement `strnlen()` Ammar Faizi
2022-03-24  7:30 ` [PATCH v1 11/11] tools/include/string: Implement `strdup()` and `strndup()` Ammar Faizi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox