Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: What integer C type to use
Date: Fri, 15 Mar 2024 20:11:36 +0000
Organization: Rocksolid Light
Message-ID: <277280765e037dd0fc556e2fc4bc4912@www.novabbs.org>
References: <upq0cr$6b5m$1@dont-email.me> <ur0ka6$23ma8$1@dont-email.me> <dd9c82c9be34460dc6fea35c8608e51d@www.novabbs.org> <2024Feb20.083240@mips.complang.tuwien.ac.at> <2024Feb20.130029@mips.complang.tuwien.ac.at> <ur2jpf$2j800$1@dont-email.me> <2024Feb20.184737@mips.complang.tuwien.ac.at> <uraof0$kij0$1@newsreader4.netcologne.de> <3a1c5c42222d44ea006bc20d55e0c94c@www.novabbs.org> <urfcgs$1rne2$1@dont-email.me> <dbaa17babbd2ca8362fad9f9ecd4b79c@www.novabbs.org> <usp9un$7pij$1@dont-email.me> <20240312144428.000063f5@yahoo.com> <19da68f1b874758d42b64203741c325b@www.novabbs.org> <20240312194918.00002cde@yahoo.com> <db785354ebf90ee6f613fc9c39f8ca72@www.novabbs.org> <20240313110859.000024e9@yahoo.com> <jwva5n2m1lr.fsf-monnier+comp.arch@gnu.org> <3186c85221c1baff1a23a46449dadd19@www.novabbs.org> <ut0gsm$23m79$1@dont-email.me> <34935c02188495cad04991abacecdf97@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="2109158"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="PGd4t4cXnWwgUWG9VtTiCsm47oOWbHLcTr4rYoM0Edo";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$wgUw9GaKeWo/ljLil6Yb7uIBUDshB6HCH2Hkv3PqX3ZLlsJlRVpF.
Bytes: 2833
Lines: 28

MitchAlsup1 wrote:

> Paul A. Clayton wrote:

>> On 3/13/24 3:24 PM, MitchAlsup1 wrote:
>>> Stefan Monnier wrote:
>> [snip]
>>>> So, short vectors have a fairly free hand at shuffling data across their
>>>> vector (e.g. bitmatrix transpose), and they can be
>>>> implemented/scheduled/dispatched just like any other instruction, but
>>>> the vector length tends to be severely limited and exposed all over
>>>> the place.
>>> 
>>> Consuming OpCode space like nobody's business.

>> Is that necessarily the case? Excluding the shuffle operations, I
>> think only loads and stores would need to have length specifiers.

> Add signed byte add unsigned byte, add signed half, add unsigned half
> add signed int, add unsigned int, add long, add 2 floats, add double

All of the above come in 64-bit, 128-bit, 256-bit, and 512-bit variants.

> compared to ADD integer, add float and add double.

> And then there is the addsub group, too.

> I may be possible to avoid OpCode explosion, but neither x86, nor ARM
> got anywhere close to avoiding the deluge of OpCodes.