[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230504161451.GE4163@brightrain.aerifal.cx>
Date: Thu, 4 May 2023 12:14:52 -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 05:53:57PM +0200, Jₑₙₛ Gustedt wrote:
> Rich,
>
> on Thu, 4 May 2023 10:30:53 -0400 you (Rich Felker <dalias@...c.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.
I don't expect you do to this work for us. It's something myself or
anyone else working on musl stuff can do and that your patches can
just assume is already present in musl by a name like __pop_arg_int128
or something.
> > 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.
__intscan only needs mul, not div, and mul is the easy side. It's
printf that needs div, and 10 is the only non-power-of-two base there.
In the case of __intscan, I'd just change the signature to return an
int128 tuple struct, and switch to using it when the value no longer
fits in smaller type. The "lim" argument mechanism needs some change
too I think. No need for a different variant of the function for
int128; the whole point of the way it's implemented is not to have
multiple versions of it for different types.
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.
