[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230504143052.GB4163@brightrain.aerifal.cx>
Date: Thu, 4 May 2023 10:30:53 -0400
From: Rich Felker <dalias@...c.org>
To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr>
Cc: musl@...ts.openwall.com
Subject: Re: patches for C23
On Thu, May 04, 2023 at 08:48:46AM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
>
> on Wed, 3 May 2023 15:33:26 -0400 you (Rich Felker <dalias@...c.org>)
> wrote:
>
> > On Wed, May 03, 2023 at 08:46:56PM +0200, Jₑₙₛ Gustedt wrote:
> > > Rich,
> > >
> > > on Wed, 3 May 2023 13:28:02 -0400 you (Rich Felker
> > > <dalias@...c.org>) wrote:
> > >
> > > > On Wed, May 03, 2023 at 05:11:11PM +0200, Jₑₙₛ Gustedt wrote:
> > [...]
> > [...]
> > > > [...]
> > > > [...]
> > [...]
> > [...]
> > > >
> > > > Again, there are not multiple versions of musl with different
> > > > features depending on which compiler was used to compile them.
> > > > There is one unified feature set. There are not configure-time or
> > > > compile-time decisions about which features to support.
> > >
> > > This sounds a bit dogmatic
> >
> > Yes, it's one of the core principles of musl: that we don't have
> > build-time-selectable feature-set like uclibc did.
> >
> > > and also unrealistic. As said the dependency
> > > on compiler builtins undermines that approach. Future versions of
> > > gcc and clang will soon support `va_start` with only one parameter
> > > for example. Musl will just be dependent on that compiler feature.
> >
> > No it won't. None of the code in musl calls or needs to call va_start
> > with one parameter. You're confusing
>
> ??
Either your statement that "musl will be dependent on that compiler
feature" is inaccutate or I'm misunderstanding what you mean. The code
in musl does not call va_start wth only one parameter.
If you mean "in order to provide a conforming C23 compilation
environment for applications, the compiler must support a
single-parameter va_start built-in", this is true, but it's obvious
that to compile C23 applications you need a C23 compiler (or compiler
with at least the subset of C23 that you need). This is the
application depending on it, not musl depending on it.
> > > availability of `__int128` dependent on `UINTPTR_WIDTH` being 64,
> > > would that be acceptable for you? Or an even more dependent approach
> > > with special casing architectures where this is available since
> > > always?
> >
> > It's not really "special casing archs where this is available since
> > always". It's more like the other way around, "not special casing
> > archs where __int128 is a guaranteed part of the baseline psABI". For
> > those we can just let the default C implementation be used. For the
> > rest we need a (completely trivial) asm stub that pops the arg
> > according to the variadic argument ABI for the arch. This really isn't
> > that big a deal. It's a few instructions at most.
>
> I would still prefer that on those archs where there is `__int128` or
> `_BitInt(128)` (for the latter basically all C23 compilers, I think)
> that the default is done with that compiler support. We should leave
> to the compiler people what they do best ;-)
Note that you can use gcc -S to generate the asm, clean up any cruft
in it, and commit the output to git, using a function like this:
struct int128_s { uint64_t a, b; };
union u { __int128 x; struct int128_s s; };
struct int128_s __pop_arg_int128(va_list *ap)
{
return (union u){ .x = va_arg(*ap, __int128) }.s;
}
> This leaves us with fallback code to write that will probably rarely
> be used. Also, I have difficulties to asses the effort that is
> needed.
See above.
> There are the `printf`, `scanf` and the new bit-fiddeling
> interfaces.
For scanf, no special va_list support is needed. It makes use of the
POSIX allowance to read pointer arguments as void *, and just stores
via them. All it needs to do is format the int128 in memory and memcpy
to the void *.
> For the latter the current proposal is to have them
> implemented as shallow static inline functions. That would a bit
> complicated without compiler support.
Do the bit-fiddling interfaces require external function definitions,
or are macro-only implementations allowed? In case of the latter, yes,
you absolutely can assume a compiler that supports whatever type is
being used, since they're compiled by the compiler that is building
the application, not the compiler that is building musl.
> In all to me this sounds like a substantial effort in implementation
> and coordination. What is the way forward, here?
I don't think it's actually all that much.
The popping thunks can be generated from the above mechanically for
all archs.
The main remaining code is writing explicit long mul/div for operating
on a struct representing int128 in two int64s which can be used in
printf and scanf/strto*. The div is only /10, so I think it can be
quite compact (vs arbitrary 128-bit division which would be nasty).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
