Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Byte Addressability And Beyond
Date: Mon, 6 May 2024 21:32:53 -0500
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <v1c3so$3195m$1@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me>
 <2024May3.171330@mips.complang.tuwien.ac.at> <v13olm$p9ih$9@dont-email.me>
 <2024May4.111127@mips.complang.tuwien.ac.at>
 <AnsZN.60734$gF_b.49289@fx17.iad> <v17dav$1o21q$2@dont-email.me>
 <YCNZN.77960$yf_8.61501@fx14.iad> <v18m0s$213qm$1@dont-email.me>
 <642cb7511c41a3931b06f747ea2161e4@www.novabbs.org>
 <v19d1t$2a6f8$1@dont-email.me> <v19gl2$2b44k$1@dont-email.me>
 <e10bcaa4cbad7113a2e630a236039c59@www.novabbs.org>
 <v1bigv$2q19c$1@dont-email.me>
 <0c13eeb8c7766f2900ee2f55f788a366@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 07 May 2024 04:32:57 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ea119fe9193b4c647c8da7860842de5d";
	logging-data="3187894"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Vo2xDGiIGDnAjKoJzD5gBDOPi1eRjfvU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:AllOQe1sgjkSSiN7Wpk/K+NcW+E=
Content-Language: en-US
In-Reply-To: <0c13eeb8c7766f2900ee2f55f788a366@www.novabbs.org>
Bytes: 4698

On 5/6/2024 7:53 PM, MitchAlsup1 wrote:
> BGB wrote:
> 
>> On 5/6/2024 2:11 PM, MitchAlsup1 wrote:
>>> Lawrence D'Oliveiro wrote:
>>>
>>>> On Sun, 5 May 2024 20:50:51 -0500, BGB wrote:
>>>
>>>>> Say, RISC-V:
>>>>>    Says yes to DIV and MOD;
>>>>>    Says yes to 4-register floating-point multiple-accumulate; Say 
>>>>> no to
>>>>>    register-indexed Load/Store.
>>>>> Me: This is not a good balance...
>>>
>>>> Multiply-accumulate is at least as much about reducing rounding 
>>>> error as about speed.
>>>
>>> It is also an IEEE 754-2008+ requirement.
> 
>> And... I have a version that just sort of works well enough to make 
>> RV64G work, but is sort of a fail on the other fronts:
>>    Using it is slower than separate ops;
>>    It produces a double-rounded result.
>>    Also, well, the FMUL isn't super accurate either.
> 
> So, it fails IEEE 754-accuracy requirements.
> 
>> FMUL is implemented in a way where it only generates the high-half of 
>> the multiply, which makes the FPU cheaper, but:
>>    Does not give strict 0.5ULP rounding.
> 
> Also failing EEE 754-accuracy requirements.
> 

Yes, but then again, I make no claim that it is IEEE-754 conformant, 
merely that it uses the same formats, and is "good enough" for most 
stuff one needs an FPU for.



>> Some combination of factors leads to the inability of Newton-Raphson 
>> to fully converge, possibly either due to omitting the low-order 
>> multiplier results, or the carry-propagation limitation for rounding 
>> (if the rounding would result in more than 8 bits of carry, it is 
>> skipped).
> 
> Newton-Raphson is dependent on getting the bits right so that its
> interpolation (between iterations) converges properly.
> 

Yeah, it gets "most of the way" and then usually gets stuck at the last 
4 bits or so.

For most uses though, this is OK, as one has the other 48 bits which are 
still generally correct.


>> Not likely to do proper FMA, as this would make a Binary64 FPU too 
>> expensive (and, doing Binary64 poorly is still preferable for most 
>> uses to not doing it at all).
> 
> And yet, every other non FPGA implementation achieves those requirements.
> 
> It really seams that your medium is influencing your architecture,
> rather than the other way around.
> 

Possibly.

Many other FPGA based soft-core processors either lack an FPU, implement 
single-precision only (such as MicroBlaze), or make similar compromises.

One of the exceptions here is SWeRV (RV32GC), but it also eats a 
considerable number of LUTs and runs at a fairly low clock speed, though 
unclear how much of this is due to the FPU, or to other factors.


>> Granted, not entirely sure how the 8087 managed to do all the stuff 
>> that it did. Since, it seems like an 80s ASIC would be more cramped 
>> than a modern Artix-7.
> 
> Mostly it was simply slow.
> 

Hmm...

A slow FPU is much less useful for most things than an inaccurate FPU.


OTOH, probably couldn't exactly do floating point in software all that 
quickly on an 8088 or 8086. I guess that mostly just leaves fixed point 
and similar.


>> ....