Rich, on Thu, 4 May 2023 10:30:53 -0400 you (Rich Felker ) 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 ::