Re: [musl] patches for C23

["Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]

Rich,

on Thu, 4 May 2023 10:30:53 -0400 you (Rich Felker <dalias@libc.org>)
wrote:

> > > You're confusing  
> > 
> > ??  

> Note that you can use gcc -S to generate the asm,

sure

> 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.

Yes, sure, what is worrying me is not to do that for one architecture
that I have and know some about (well certainly have to learn things,
but that's ok) but to have that for all architectures, to which I
don't have access and that may have asm fiddling that I don't know
about.

> > 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?


They are required for the three usual wide unsigned integer types. The
type-generic interface is supposed to work for all wide standard and
extended integer types (not including `_BitInt(N)` for weird `N`). So
the most natural here would be to add functions for the 128 bit
types. Also the generic code that just dispatches inline function
pointers is much easier and clearer. `_Generic` for function or macro
calls (in contrast to just function pointers) is much nastier, because
all branches must be valid C and should not drown us in
false-positives.

> 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.

A macro version is certainly doable, there is such a version in the
patches already, but it is much nastier.

But for all of this, the separation in two chunks of 64 bit and
assembling the result is already done.

> > 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.

Yes, but only for people that have access to these archs. So this is
much more effort than me writing some code and having it reviewed by
you guys.

> 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).

Yes, I figured that. Some of that for bases 16 and 10 should already
be there in the floating point code, I imagine. But still this is not
so easy to read from the start, and would need good review and
testing. And our internal dispatch `__intscan` accept bases from 2 to
36, so there is either a bit more than 10 and 16 to cover, or a
special instantiation of the function as used by `scanf` for 128 types
has to be created.

Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]