From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59105 invoked by alias); 18 Feb 2019 19:51:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 59078 invoked by uid 89); 18 Feb 2019 19:51:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=life X-HELO: mail-wm1-f44.google.com Received: from mail-wm1-f44.google.com (HELO mail-wm1-f44.google.com) (209.85.128.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Feb 2019 19:51:23 +0000 Received: by mail-wm1-f44.google.com with SMTP id z84so271572wmg.4 for ; Mon, 18 Feb 2019 11:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7wmeDuTpVtkh93oP5PXp8DXjaliz/itL6x8XDheYV7M=; b=lUonKz2ZFA1PtuojVsesNS5dOawd6PXQW4F1IsoBCmmC6ubV46ruHYFjwLQZ2YSF2k MkMClMfY7x+ga0pZf8RGfSHRTR0nkzUKFn3LW6oQHqfNm3Zdhvag++R5xiqW1NN1x4H1 BmiNVCKc5uWLDwD4B1sXM3QWK7rNAiSn09LyqK0Q4bjWEz+YpdhwK++/heIiulaxUSuL zdGIyYxlb9J5+n1I8KwoGczeGIWepvM45VusxTp+JZyl/1+tKExTCyrBXYn/dbyTwq/O y5f4o4t8dKazkDGzqjTM3DfysBt30HdadS1SjjiQsfC0+jmFdfrB0k4mldKd34MPc9Zl XT3w== MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Mon, 18 Feb 2019 19:51:00 -0000 Message-ID: Subject: Re: Idea: extend gcc to save C from the hell of intel vector instructions To: Warren D Smith Cc: GCC Mailing List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00095.txt.bz2 On Mon, Feb 18, 2019 at 11:15 AM Warren D Smith wrote: > > There are a lot of weird intel vector instructions like > #include > > __m128i alignas(16) A, B, C, D, X, Y; > A = _mm_shuffle_epi8(D, Y); > C = _mm_unpackhi_epi16(A, B); > where my gcc seems to know about the latter but not the former > (I have no idea why, and it is very annoying to arbitrarily support the second > and not the first). > > Anyhow. If you write code like that, it is horrible to read. > > But here is a simple idea for improving the C language which would make > lots of such code easy to read. And write. > > First of all, there should be (and pretty much are, see stdint.h, inttypes.h) > int and uint types of various power of 2 bit sizes, e.g. > > int16 a; > uint64 b; > uint128 c; > > uint256 d; > uint512 e; > uint4 f; > > where again my gcc supports the first 3 (after appropriate renamings) > but not the last 3. (Again, very annoying arbitrariness.) > > But more importantly, we should add new types like this: > > uint128.16 a, b; > meaning a is 128 bits wide, and consists of 16 chunks, each 8 bits wide, > each regarded as an 8-bit-wide unsigned int. > > uint256.8 y, z; > and so on. > > Note the use of DOTS inside the type name. You could consider other notations, > I am not fixated on this one. Another might be uint128{16}. > > OK, now we could do > uint128.16 a, b, c; > c = a+b; //adds the 16-element vectors a and b elementwise > c = a-b; //subtracts vectors > etc. > > Life is SO much nicer now. It's practically sane again. GCC already has most of this support. See https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Vector-Extensions.html#Vector-Extensions The dot in the typenames are not going to supported though. Thanks, Andrew > > Don't have to keep coming up with all the horrible > names for each possible kind of vector operation, the compiler does it for you. > Compiler can check type compatibility and complain if try to > add incompatible types. etc etc. > > And for stuff that really should have funny names, > b = shuffle(c, d) > will have meaning pretty obvious from the types of b,c,d, > and again can complain about type mismatches. > And the type names will no longer be horrible unreadable strings of > nonsense characters. > They will be perfectly readable and logical simple names like uint128.16. > > The present hellish situation is partly intel's fault and partly gcc's fault, > but it is absurd, that is for sure, and this hell is entirely > unnecessary, that is > what really rubs your face in it over and over. > > -- > Warren D. Smith > http://RangeVoting.org <-- add your endorsement (by clicking > "endorse" as 1st step)