[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1390215339.6398.371.camel@eris.loria.fr>
Date: Mon, 20 Jan 2014 11:55:39 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Discussion of partly-invasive changes needed for x32 port
Am Montag, den 20.01.2014, 11:12 +0100 schrieb John Spencer:
> what rich had in mind was usage of _Generic in the x32 __scc
> (syscall-cast) macro:
>
> instead of
>
> #define __scc(X) sizeof(1?(X):0ULL) < 8 ? (unsigned long) (X) : (long
> long) (X)
>
> something along the lines of
> _Generic((X), struct timespec*: &(struct timespec){.sec = (X).sec, .nsec
> = (X).nsec}, default: sizeof(1?(X):0ULL) < 8 ? (unsigned long) (X) :
> (long long) (X))
ah, I see how _Generic could pop in an make some wrappers for
architecture specific code nicer
In the concrete case I don't understand too well. The return type of
that generic expression would be of a fundamentally different type,
once a pointer to struct, otherwise an integer. Also the two struct
types should be different types, no? One the userland type and the
other the kernel type?
But then something like
&(struct kernel_timespec){.sec = (X)->sec, .nsec = (X)->nsec}
should suffice to capture the transition well.
This would certainly benefit of a wrapper function
kernel_timespec_copy, because it evaluates X twice :
kernel_timespec_copy(&(struct kernel_timespec){0}, (X))
If you want that for optimization reasons you could try to capture if
the two types agree and avoid the extra copy. Something along the
line of
_Generic((X),
struct kernel_timespec*: (X),
default: kernel_timespec_copy(&(struct kernel_timespec*){0}, (X))
)
But I am not convinced that this can't be just achieved by doing some
#ifdef programming
> however the only available compiler implementing _Generic is Clang.
> not even GCC 4.8.2 supports it. however i've seen some pseudo _Generic
> implementation on your blog [1], imo we could use the bits described
> there, namely
> "
> __typeof__(EXP) gives the type of the expression EXP
> __builtin_types_compatible_p(T1, T2) is true if the two types are
> compatible
> __builtin_choose_expr(CNTRL, EXP1, EXP2) choose between the two
> expressions at compile time.
> "
>
> to implement the above macro, as x32 requires a very recent GCC (>= 4.7)
> anyway, i see no big problem in using those gcc helpers in lieu of _Generic.
These features are supported since long in gcc and clang, I think, so
yes from that side there certainly would be not much of an obstacle.
But I wouldn't think that using such a feature just in such an
isolated spot (very restricted part of code and very specific
architecture) would be worth it.
Some cooked down version of _Generic could perhaps be beneficial for
the whole of musl, there are some places that implement type
genericity in some handcrafted way. But these things need macro magic
and should not be re-implemented at each point where they are
needed. So probably much too intrusive at this point in time.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
