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: Cray style vectors
Date: Tue, 12 Mar 2024 19:07:01 +0000
Organization: Rocksolid Light
Message-ID: <aac798f6f6b611c624b1bb0ad1f7d30a@www.novabbs.org>
References: <upq0cr$6b5m$1@dont-email.me> <uqhiqb$2grub$1@dont-email.me> <uqlm2c$3e9bp$1@dont-email.me> <uqmn7c$3n35k$1@dont-email.me> <2024Feb16.082736@mips.complang.tuwien.ac.at> <uqnmue$3o4m9$1@dont-email.me> <2024Feb16.152320@mips.complang.tuwien.ac.at> <uqobhv$3o4m9$2@dont-email.me> <1067c5b46cebaa18a0fc50fc423aa86a@www.novabbs.com> <uqpngc$3o4m9$3@dont-email.me> <uqpuid$bhg0$1@dont-email.me> <2024Feb17.190353@mips.complang.tuwien.ac.at> <uqqvkc$i2cu$1@dont-email.me> <uqvk2o$1snbf$1@dont-email.me> <ur1h0v$emi4$1@newsreader4.netcologne.de> <86r0h6wyil.fsf@linuxsc.com> <ur7v2r$ipnu$1@newsreader4.netcologne.de> <861q91ulhs.fsf@linuxsc.com> <urkbsu$34rpk$1@dont-email.me> <864jdcsqmn.fsf@linuxsc.com> <usp8lp$7i96$1@dont-email.me> <86jzm7qqdk.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1761041"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="PGd4t4cXnWwgUWG9VtTiCsm47oOWbHLcTr4rYoM0Edo";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$7iZVR7cd29uRHli93.Y0suTKSRE35/PTgbW9JjDonAwjHuo8xGu7.
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3868
Lines: 50

Tim Rentsch wrote:

> Terje Mathisen <terje.mathisen@tmsw.no> writes:

>> Tim Rentsch wrote:
>>
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> If I really had to write a 64x64->128 MUL, with no widening MUL or
>>>> MULH which returns the high half, then I would punt and do it using
>>>> 32-bit parts (all variables are u64):  [...]
>>>
>>> I wrote some code along the same lines.  A difference is you
>>> are considering unsigned multiplication, and I am considering
>>> signed multiplication.
>>
>> Signed mul is just a special case of unsigned mul, right?
>>
>> I.e. in case of a signed widening mul, you'd first extract the signs,
>> convert the inputs to unsigned, then do the unsigned widening mul,
>> before finally resotirng the sign as the XOR of the input signs?
>>
>> There is a small gotcha if either of the inputs are of the 0x80000000
>> form, i.e. MININT, but the naive iabs() conversion will do the right
>> thing by leaving the input unchanged.
>>
>> At the other end there cannot be any issues since restoring a negative
>> output sign cannot overflow/fail.

> It isn't quite that simple.  Some of what you describe has a risk
> of running afoul of implementation-defined behavior or undefined
> behavior (as for example abs( INT_MIN )).  I'm pretty sure it's
> possible to avoid those pitfalls, but it requires a fair amount
> of care and careful thinking.

It would be supremely nice if we could go back in time before 
computers and reserve an integer encoding that represents the
value of "there is no value here" and mandate if upon integer 
arithmetic.

> Note that my goal is only to avoid the possibility of undefined
> behavior that comes from signed overflow.  My approach is to safely
> determine whether the signed multiplication would overflow, and if
> it wouldn't then simply use signed arithmetic to get the result.

Double width multiplication cannot overflow. 2n = n×n then, ignoring
the top n bits gives you your non-overflowing multiply.

> I use unsigned types to determine the safety, and if it's safe then
> using signed types to get a result.  For the current problem I don't
> care about widening, except as it might help to determine safety.