Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

The nicest thing about the Alto is that it doesn't run faster at night.


devel / comp.arch / Re: Mixed EGU/EGO floating-point

SubjectAuthor
* Mixed EGU/EGO floating-pointQuadibloc
`* Re: Mixed EGU/EGO floating-pointMitchAlsup
 +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |`- Re: Mixed EGU/EGO floating-pointQuadibloc
 +* Re: Mixed EGU/EGO floating-pointQuadibloc
 |`* Re: Mixed EGU/EGO floating-pointAnton Ertl
 | +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 | |`- Re: Mixed EGU/EGO floating-pointMichael S
 | +* Re: Mixed EGU/EGO floating-pointJohn Levine
 | |+- Re: Mixed EGU/EGO floating-pointJohn Dallman
 | |+- Re: Mixed EGU/EGO floating-pointAnton Ertl
 | |+* Re: Mixed EGU/EGO floating-pointJimBrakefield
 | ||`- Re: Mixed EGU/EGO floating-pointEricP
 | |`- Re: Mixed EGU/EGO floating-pointMichael S
 | `* Re: Mixed EGU/EGO floating-pointTerje Mathisen
 |  +* Re: Mixed EGU/EGO floating-pointIvan Godard
 |  |+* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||`- Re: Mixed EGU/EGO floating-pointIvan Godard
 |  |+* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||`* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  || +* Re: Mixed EGU/EGO floating-pointEricP
 |  || |+* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  || ||`- Re: Mixed EGU/EGO floating-pointBGB
 |  || |+- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  || |`* Re: Mixed EGU/EGO floating-pointStephen Fuld
 |  || | +- Re: Mixed EGU/EGO floating-pointEricP
 |  || | +- Re: Mixed EGU/EGO floating-pointJohn Levine
 |  || | +* Re: Mixed EGU/EGO floating-pointTerje Mathisen
 |  || | |`- Re: Mixed EGU/EGO floating-pointIvan Godard
 |  || | `- Re: Mixed EGU/EGO floating-pointGeorge Neuner
 |  || +* Re: Mixed EGU/EGO floating-pointStephen Fuld
 |  || |`- Re: Mixed EGU/EGO floating-pointEricP
 |  || +- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  || `* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||  `* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  ||   +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   |`* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  ||   | +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | |+* Re: Mixed EGU/EGO floating-pointStefan Monnier
 |  ||   | ||+- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | ||`* Re: Mixed EGU/EGO floating-pointIvan Godard
 |  ||   | || `* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | ||  `* Re: Mixed EGU/EGO floating-pointBGB
 |  ||   | ||   `* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | ||    `- Re: Mixed EGU/EGO floating-pointBGB
 |  ||   | |`* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||   | | `- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||   | `* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||   |  `- Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  ||   `* Re: Mixed EGU/EGO floating-pointAnton Ertl
 |  ||    +* Re: Mixed EGU/EGO floating-pointBGB
 |  ||    |`- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  ||    `* Re: Mixed EGU/EGO floating-pointThomas Koenig
 |  ||     `- Re: Mixed EGU/EGO floating-pointMitchAlsup
 |  |`- Re: Mixed EGU/EGO floating-pointTerje Mathisen
 |  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |   `- Re: Mixed EGU/EGO floating-pointBGB
 +* Re: Mixed EGU/EGO floating-pointJimBrakefield
 |`* Re: Mixed EGU/EGO floating-pointQuadibloc
 | +* Re: Mixed EGU/EGO floating-pointMitchAlsup
 | |+- Re: Mixed EGU/EGO floating-pointJimBrakefield
 | |`* Perfect roudning of trogonometric functions (was: Mixed EGU/EGO floating-point)Stefan Monnier
 | | `* Re: Perfect roudning of trogonometric functionsTerje Mathisen
 | |  `* Re: Perfect roudning of trogonometric functionsStefan Monnier
 | |   `- Re: Perfect roudning of trogonometric functionsTerje Mathisen
 | `* Re: Mixed EGU/EGO floating-pointEricP
 |  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
 |   +- Re: Mixed EGU/EGO floating-pointJimBrakefield
 |   +- Re: Mixed EGU/EGO floating-pointTerje Mathisen
 |   `- Re: Mixed EGU/EGO floating-pointEricP
 `* Re: Mixed EGU/EGO floating-pointBGB
  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   +* Re: Mixed EGU/EGO floating-pointStefan Monnier
   |`* Re: Mixed EGU/EGO floating-pointBGB
   | `* Re: Mixed EGU/EGO floating-pointJohn Dallman
   |  +- Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  +* Re: Mixed EGU/EGO floating-pointThomas Koenig
   |  |+- Re: Mixed EGU/EGO floating-pointJohn Dallman
   |  |+* Re: Mixed EGU/EGO floating-pointBGB
   |  ||`* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  || `* Re: Mixed EGU/EGO floating-pointBGB
   |  ||  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  ||   +* Re: Mixed EGU/EGO floating-pointIvan Godard
   |  ||   |`- Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  ||   `* Re: Mixed EGU/EGO floating-pointBGB
   |  ||    `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  ||     `* Re: Mixed EGU/EGO floating-pointBGB
   |  ||      `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  ||       `- Re: Mixed EGU/EGO floating-pointBGB
   |  |`* Re: Mixed EGU/EGO floating-pointAnton Ertl
   |  | `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  |  +* Re: Mixed EGU/EGO floating-pointQuadibloc
   |  |  |+- Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  |  |`* Re: Mixed EGU/EGO floating-pointAnton Ertl
   |  |  | `- Re: Mixed EGU/EGO floating-pointQuadibloc
   |  |  `* Re: Mixed EGU/EGO floating-pointAnton Ertl
   |  |   `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  |    +* Re: Mixed EGU/EGO floating-pointBGB
   |  |    |`* Re: Mixed EGU/EGO floating-pointBGB
   |  |    | `* Re: Mixed EGU/EGO floating-pointQuadibloc
   |  |    |  +- Re: Mixed EGU/EGO floating-pointBGB
   |  |    |  `* Re: Mixed EGU/EGO floating-pointMitchAlsup
   |  |    +- Re: Mixed EGU/EGO floating-pointAnton Ertl
   |  |    `- Re: Mixed EGU/EGO floating-pointQuadibloc
   |  `* Re: Mixed EGU/EGO floating-pointQuadibloc
   `* Re: Mixed EGU/EGO floating-pointBGB

Pages:12345
Re: Mixed EGU/EGO floating-point

<t60aob$fb6$3@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25395&group=comp.arch#25395

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-5c6-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Tue, 17 May 2022 14:16:43 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t60aob$fb6$3@newsreader4.netcologne.de>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
<t5r53e$cjh$1@newsreader4.netcologne.de>
<2022May15.193827@mips.complang.tuwien.ac.at>
<t5re2t$h0o$1@newsreader4.netcologne.de>
<6c1f724c-278a-43fe-8aab-efed4a1a310bn@googlegroups.com>
<t5rm0u$kor$1@newsreader4.netcologne.de>
<2022May16.095507@mips.complang.tuwien.ac.at>
Injection-Date: Tue, 17 May 2022 14:16:43 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-5c6-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:5c6:0:7285:c2ff:fe6c:992d";
logging-data="15718"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Tue, 17 May 2022 14:16 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>MitchAlsup <MitchAlsup@aol.com> schrieb:
>>> On Sunday, May 15, 2022 at 12:42:56 PM UTC-5, Thomas Koenig wrote:
>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>> > Thomas Koenig <tko...@netcologne.de> writes:
>>>> >>Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>> >>
>>>> >>> No, we already have NaNs for that. He wants to be able to compute the
>>>> >>> sum/product of all present data, and what he proposes works for that.
>>>> >>
>>>> >> s = sum(a,mask=.not. ieee_is_nan(a))
>>>> >>
>>>> >>works fine.
> ...
>>And my actual point: No sense in implementing something in a floating
>>point format that can be be much better handled by code like the one
>>above (or the equivalent C code).
>
> Please demonstrate "much better".

Suitable to be adapted to the task at hand, which is what software
is for.

How do deal with missing data is totally dependent on the use case,
and a one-size-fits-all solution is bound to bring nothing useful
to the majority of use cases where data might indeed be missing.

(Just think about sensor data, where a value might indeed be missing,
or invalid, or offscale high, or offscale low, or somebody bumped into
the apparatus).

Re: Mixed EGU/EGO floating-point

<2022May17.160703@mips.complang.tuwien.ac.at>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25396&group=comp.arch#25396

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: ant...@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Tue, 17 May 2022 14:07:03 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 38
Message-ID: <2022May17.160703@mips.complang.tuwien.ac.at>
References: <t5qe8t$fh0$1@dont-email.me> <memo.20220515153920.11824J@jgd.cix.co.uk> <t5rco4$ga5$1@newsreader4.netcologne.de> <2022May16.114735@mips.complang.tuwien.ac.at> <60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com> <2022May16.222811@mips.complang.tuwien.ac.at> <25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="a6c93b3a07299dfb70710467893880db";
logging-data="24591"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19cY14BLRhAB+drePu+HZfm"
Cancel-Lock: sha1:lpPJZHhpVnGRTm3VR0qJifExELo=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Tue, 17 May 2022 14:07 UTC

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, May 16, 2022 at 3:39:46 PM UTC-5, Anton Ertl wrote:
>> x86-64 is an older name for AMD64.
><
>You don't name a baby "bob" and then years later reman him "joe"

Maybe not with babies (but that differs by culture), but it's common
for architectures.

I can understand why AMD called it x86-64 at first, but

* it's based on the x86 misconception (as if IA-32 was an extended
8086 instuction set).

* It's hard to pronounce and type (plus, some people type it x86_64).

>> Java defined IEEE 754, and all other architectures provided that, but
>> 387 didn't quite (although it was very close). And IIRC even if you
>> stored the values to memory after every operation, you still could run
>> into double-rounding problems.
><
>Would if have been possible for java to define FP calculations in a way
>that x87 would have been acceptable as was ?

They would have needed to abandon bit-compatibility, or define FP
calculations in a way incompatible with the rest of the architectures
(including their own SPARC).

In practice, AFAIK the result was bit-incompatibility for doubles;
that was more acceptable than the performance cost of implementing
bit-exact IEEE DP FP in software. For floats, storing the result of
every operation to memory should produce bit-compatible results even
on the 387.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Re: Mixed EGU/EGO floating-point

<f6233a22-95c9-49f7-8dd3-912a65dc7be7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25398&group=comp.arch#25398

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:4e42:0:b0:2f4:fc3c:b0c8 with SMTP id e2-20020ac84e42000000b002f4fc3cb0c8mr20785731qtw.684.1652805358374;
Tue, 17 May 2022 09:35:58 -0700 (PDT)
X-Received: by 2002:a05:6870:80ca:b0:f1:8fad:d9d1 with SMTP id
r10-20020a05687080ca00b000f18fadd9d1mr7888993oab.125.1652805358197; Tue, 17
May 2022 09:35:58 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 17 May 2022 09:35:57 -0700 (PDT)
In-Reply-To: <t5vg7m$3is$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b906:a655:bfcf:bf2f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b906:a655:bfcf:bf2f
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
<t5r53e$cjh$1@newsreader4.netcologne.de> <2022May15.193827@mips.complang.tuwien.ac.at>
<t5re2t$h0o$1@newsreader4.netcologne.de> <2022May16.080036@mips.complang.tuwien.ac.at>
<t5vg7m$3is$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f6233a22-95c9-49f7-8dd3-912a65dc7be7n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 17 May 2022 16:35:58 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3638
 by: MitchAlsup - Tue, 17 May 2022 16:35 UTC

On Tuesday, May 17, 2022 at 1:44:10 AM UTC-5, BGB wrote:
> On 5/16/2022 1:00 AM, Anton Ertl wrote:
> > Thomas Koenig <tko...@netcologne.de> writes:
> >> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >>>>
> >>>>> No, we already have NaNs for that. He wants to be able to compute the
> >>>>> sum/product of all present data, and what he proposes works for that.
> >>>>
> >>>> s = sum(a,mask=.not. ieee_is_nan(a))
> >>>>
> >>>> works fine.
> >>>
> >>> Which CPU has this instruction?
> >>
> >> Any processor which implements Fortran.
> >
> > I.e., none.
> >
> Hmm, my case, could do it something like:
> FCMPEQ R4, R4
> FADD?T R8, R4, R8
>
> This would filter out all NaNs because only NaNs compare not-equal to
> themselves...
>
>
>
> I guess it is theoretically possible one could have a tag-checking
> instruction specifically for NaNs:
> FCMPTTEQNAN Imm6u, Rn
>
> Which checks whether:
> Rn is NaN;
> If the bit-pattern (in the upper mantissa bits) matches the pattern
> encoded in the Imm6 field.
>
> Could be relevant if one expects there to be a lot of NaN-boxed data or
> similar.
>
> Could potentially be used as a cheap way of implementing "isinf()", say:
> isinf:
> FCMPTTEQNAN 0, R4 //Sets SR.T if E==11'h7FF && [51:48]==4'h0
> MOVT R2 //Copies SR.T to R2
> RTS
<
In My 66000 case:
FCMP Rt,R4,R4
// at this point Rt<6> tells you if the operands are comparable
// That is neither are NaN.
// at this point Rt<7> tells you if the operands are uncomparable
// one or both are NaN.
// You can branch/pred on the TRUE cases {==, !=, >, >=, <, <=}
// You can branch/pred on the FALSE cases {! ==, ! !=, ! >, ! >=, ! <, ! <=}
<
No new/additional instruction needed.
>
>
> But, dunno...
>
>
>
> > - anton

Re: Mixed EGU/EGO floating-point

<7150b5cd-0abd-492c-9991-bd1f213071b2n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25399&group=comp.arch#25399

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:238d:b0:461:d89a:e1f3 with SMTP id fw13-20020a056214238d00b00461d89ae1f3mr5824309qvb.118.1652805459070;
Tue, 17 May 2022 09:37:39 -0700 (PDT)
X-Received: by 2002:a05:6808:c2:b0:325:eb87:c26f with SMTP id
t2-20020a05680800c200b00325eb87c26fmr11099444oic.117.1652805458785; Tue, 17
May 2022 09:37:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.mixmin.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 17 May 2022 09:37:38 -0700 (PDT)
In-Reply-To: <t5vi1s$er3$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b906:a655:bfcf:bf2f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b906:a655:bfcf:bf2f
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
<t5r53e$cjh$1@newsreader4.netcologne.de> <2022May15.193827@mips.complang.tuwien.ac.at>
<t5re2t$h0o$1@newsreader4.netcologne.de> <6c1f724c-278a-43fe-8aab-efed4a1a310bn@googlegroups.com>
<t5rm0u$kor$1@newsreader4.netcologne.de> <380df37d-3cf9-4bcc-a599-c31ac300137cn@googlegroups.com>
<jwvsfpabftk.fsf-monnier+comp.arch@gnu.org> <t5sah1$ara$2@dont-email.me>
<337779ea-5572-4cf6-a663-d0ab990ecbbdn@googlegroups.com> <t5vi1s$er3$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7150b5cd-0abd-492c-9991-bd1f213071b2n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 17 May 2022 16:37:39 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Tue, 17 May 2022 16:37 UTC

On Tuesday, May 17, 2022 at 2:15:12 AM UTC-5, BGB wrote:
> On 5/15/2022 9:02 PM, MitchAlsup wrote:
> > On Sunday, May 15, 2022 at 8:48:20 PM UTC-5, Ivan Godard wrote:
> >> On 5/15/2022 3:20 PM, Stefan Monnier wrote:
> >>>> While My 66000 has instructions FMAX and FMIN and you CAN implement
> >>>> FABS as FMAX(x,-x). It saves power to have its own instruction.
> >>>
> >>> Interesting. Do you happen to know exactly where this power savings
> >>> come from? I guess it depends on how the instruction is implemented, of
> >>> course (i.e. does it have its own separate implementation in the
> >>> FP-ALU, or is it decoded into something equivalent to FMAX(x,-x), or
> >>> something in-between)?
> >>>
> >>>
> >>> Stefan
> > <
> >> FABS is a bitClear instruction.
> > <
> > But you don't even need to encode which bit to clear.
>
> FABS is at least cheap, albeit infrequently used.
>
> Did "make the cut" in my case, mostly due to its cheapness.
>
> There is also FNEG, which is also cheap, and more commonly used.
>
>
> FMIN and FMAX are less cheap, also rarely used.
>
> They do not exist in my case, but could be done as 2-op sequences:
> FCMPGT R4, R5
> CSELT R4, R5, R2
> Or:
> FCMPGT R4, R5
> CSELT R5, R4, R2
<
Do these get the "right answer" when NaNs, infinities, and denorms are used ?
>
> Or, SIMD:
> 2x Binary32:
> PCMPGT.F R4, R5
> PCSELT.L R4, R5, R2
> 4x Binary16:
> PCMPGT.H R4, R5
> PCSELT.W R4, R5, R2
> 4x Binary32:
> PCMPGT.F R4, R6
> PCSELT.L R4, R6, R2
> PCMPGT.F R5, R7
> PCSELT.L R5, R7, R3
>
> Or, "probably good enough"...

Re: Mixed EGU/EGO floating-point

<09099f9d-1503-4846-bbd0-c041e9fd15abn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25400&group=comp.arch#25400

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1007:b0:2f3:ce52:25cb with SMTP id d7-20020a05622a100700b002f3ce5225cbmr20175894qte.575.1652805690259;
Tue, 17 May 2022 09:41:30 -0700 (PDT)
X-Received: by 2002:a05:6830:1489:b0:605:e8f6:5047 with SMTP id
s9-20020a056830148900b00605e8f65047mr8183013otq.185.1652805689844; Tue, 17
May 2022 09:41:29 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 17 May 2022 09:41:29 -0700 (PDT)
In-Reply-To: <t60ab0$fb6$2@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b906:a655:bfcf:bf2f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b906:a655:bfcf:bf2f
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com> <a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
<t5r53e$cjh$1@newsreader4.netcologne.de> <2022May15.193827@mips.complang.tuwien.ac.at>
<t5re2t$h0o$1@newsreader4.netcologne.de> <2022May16.080036@mips.complang.tuwien.ac.at>
<t60ab0$fb6$2@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <09099f9d-1503-4846-bbd0-c041e9fd15abn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 17 May 2022 16:41:30 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2675
 by: MitchAlsup - Tue, 17 May 2022 16:41 UTC

On Tuesday, May 17, 2022 at 9:09:39 AM UTC-5, Thomas Koenig wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> > Thomas Koenig <tko...@netcologne.de> writes:
> >>Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >>> Thomas Koenig <tko...@netcologne.de> writes:
> >>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >>>>
> >>>>> No, we already have NaNs for that. He wants to be able to compute the
> >>>>> sum/product of all present data, and what he proposes works for that.
> >>>>
> >>>> s = sum(a,mask=.not. ieee_is_nan(a))
> >>>>
> >>>>works fine.
> >>>
> >>> Which CPU has this instruction?
> >>
> >>Any processor which implements Fortran.
> >
> > I.e., none.
> There are quite a few according to ISO/IEC 1539:2018, subclause 3.113.
<
Any machine that is Touring complete can run FORTRAN.
That does not mean that the machines are efficient at running FORTRAN
or designed for running FORTRAN
Or as good at running FORTRAN as a machine that actually was.

Re: Mixed EGU/EGO floating-point

<t60nqu$ve7$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25402&group=comp.arch#25402

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Tue, 17 May 2022 12:59:56 -0500
Organization: A noiseless patient Spider
Lines: 116
Message-ID: <t60nqu$ve7$1@dont-email.me>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com>
<2a41be98-e9c8-4159-bef7-ba7999e278ecn@googlegroups.com>
<a4400d89-ce0d-4c76-aeb2-de2d13f40318n@googlegroups.com>
<2022May13.200449@mips.complang.tuwien.ac.at> <t5p9pf$52o$1@gioia.aioe.org>
<t5pb7g$6og$1@dont-email.me> <2022May15.091837@mips.complang.tuwien.ac.at>
<t5r53e$cjh$1@newsreader4.netcologne.de>
<2022May15.193827@mips.complang.tuwien.ac.at>
<t5re2t$h0o$1@newsreader4.netcologne.de>
<6c1f724c-278a-43fe-8aab-efed4a1a310bn@googlegroups.com>
<t5rm0u$kor$1@newsreader4.netcologne.de>
<380df37d-3cf9-4bcc-a599-c31ac300137cn@googlegroups.com>
<jwvsfpabftk.fsf-monnier+comp.arch@gnu.org> <t5sah1$ara$2@dont-email.me>
<337779ea-5572-4cf6-a663-d0ab990ecbbdn@googlegroups.com>
<t5vi1s$er3$1@dont-email.me>
<7150b5cd-0abd-492c-9991-bd1f213071b2n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 17 May 2022 17:59:58 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="407bfcdffd720520a9d83d643dadfa29";
logging-data="32199"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19a8LlZb+aMcf3W1Ph2H2d4"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:QLf0RJpeqxAO/tHnMD9kBH+8e78=
In-Reply-To: <7150b5cd-0abd-492c-9991-bd1f213071b2n@googlegroups.com>
Content-Language: en-US
 by: BGB - Tue, 17 May 2022 17:59 UTC

On 5/17/2022 11:37 AM, MitchAlsup wrote:
> On Tuesday, May 17, 2022 at 2:15:12 AM UTC-5, BGB wrote:
>> On 5/15/2022 9:02 PM, MitchAlsup wrote:
>>> On Sunday, May 15, 2022 at 8:48:20 PM UTC-5, Ivan Godard wrote:
>>>> On 5/15/2022 3:20 PM, Stefan Monnier wrote:
>>>>>> While My 66000 has instructions FMAX and FMIN and you CAN implement
>>>>>> FABS as FMAX(x,-x). It saves power to have its own instruction.
>>>>>
>>>>> Interesting. Do you happen to know exactly where this power savings
>>>>> come from? I guess it depends on how the instruction is implemented, of
>>>>> course (i.e. does it have its own separate implementation in the
>>>>> FP-ALU, or is it decoded into something equivalent to FMAX(x,-x), or
>>>>> something in-between)?
>>>>>
>>>>>
>>>>> Stefan
>>> <
>>>> FABS is a bitClear instruction.
>>> <
>>> But you don't even need to encode which bit to clear.
>>
>> FABS is at least cheap, albeit infrequently used.
>>
>> Did "make the cut" in my case, mostly due to its cheapness.
>>
>> There is also FNEG, which is also cheap, and more commonly used.
>>
>>
>> FMIN and FMAX are less cheap, also rarely used.
>>
>> They do not exist in my case, but could be done as 2-op sequences:
>> FCMPGT R4, R5
>> CSELT R4, R5, R2
>> Or:
>> FCMPGT R4, R5
>> CSELT R5, R4, R2
> <
> Do these get the "right answer" when NaNs, infinities, and denorms are used ?

Excluding NaNs, yeah, sorta...

The FCMPGT operator is basically:
Perform an unsigned integer compare;
Twiddle the result based on the sign bits.
00: A>B
01: 1
10: 0
11: !(A>B)

In terms of unsigned numbers, Inf, normal-range, Denorm, and Zero, are
in the correct order.

NaN has the quirk though of being "beyond infinity" as far as FCMPGT or
similar is concerned.

In my case, neither FCMPEQ or FCMPGT implements DAZ semantics as in this
case doing so would be more expensive than not doing so (and everything
still works as expected when using FTZ).

A non-standard conversion rule is used for FLDCS/FSTCS (Single<->Double
conversion), where for the exponent, Zero maps to Zero, Mantissa bits
are kept unchanged.

This, ironically, preserves the same relative order on widening conversion.

It may however break ordering in some cases on narrowing conversions.

For Double->Single, the main converters may apply a "try to round
low-order bits" conversion. Though, the cheaper versions simply do truncate.

Or, say, for narrowing (shorthand form):
{z,yyy,xxxxxxx}=ExpA;
ExpC={z,xxxxxxx};
FraC=FraA[51:29];
if(yyy!=(~{z,z,z}))
if(yyy!={z,z,z})
ftz=1;
ExpC=z?8'hFF:8'h00;

/* Expensive converter: */
tRnd={1'b0,FraC[7:0]}+FraA[28];
if(!tRnd[8])
FraC[7:0]=tRnd[7:0];
if(ftz)
FraC=0;

For a "cheap converter" case, one can leave out the last part.
Causes truncate rounding and overflowed values to turn into NaNs, ...,
but "good enough".

With the main path (Scalar converters and FMOV.S) using the "expensive
case" logic.

Where the rounding and zeroing steps are a significant part of the cost
of the converter.

>>
>> Or, SIMD:
>> 2x Binary32:
>> PCMPGT.F R4, R5
>> PCSELT.L R4, R5, R2
>> 4x Binary16:
>> PCMPGT.H R4, R5
>> PCSELT.W R4, R5, R2
>> 4x Binary32:
>> PCMPGT.F R4, R6
>> PCSELT.L R4, R6, R2
>> PCMPGT.F R5, R7
>> PCSELT.L R5, R7, R3
>>
>> Or, "probably good enough"...

Re: Mixed EGU/EGO floating-point

<t60uh1$o8s$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25406&group=comp.arch#25406

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Tue, 17 May 2022 14:54:07 -0500
Organization: A noiseless patient Spider
Lines: 156
Message-ID: <t60uh1$o8s$1@dont-email.me>
References: <t5qe8t$fh0$1@dont-email.me>
<memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de>
<2022May16.114735@mips.complang.tuwien.ac.at>
<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>
<2022May16.222811@mips.complang.tuwien.ac.at>
<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
<t5v565$9s4$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 17 May 2022 19:54:09 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="407bfcdffd720520a9d83d643dadfa29";
logging-data="24860"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18O2zryzsxVpE+8+CNZLfT9"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:vibB40Of3FHcBmlCzA0xooXMFQA=
In-Reply-To: <t5v565$9s4$1@dont-email.me>
Content-Language: en-US
 by: BGB - Tue, 17 May 2022 19:54 UTC

On 5/16/2022 10:35 PM, BGB wrote:
> On 5/16/2022 4:25 PM, MitchAlsup wrote:
>> On Monday, May 16, 2022 at 3:39:46 PM UTC-5, Anton Ertl wrote:
>>> MitchAlsup <Mitch...@aol.com> writes:
>>>> On Monday, May 16, 2022 at 5:00:58 AM UTC-5, Anton Ertl wrote:
>>>>>> Sounds like a broken design to me. What exactly were the different
>>>>>> kinds of FP registers, and how were they different?
>>>> <
>>>>> One example that comes to my mind is IA-32/AMD64. They have the 387
>>>> <
>>>> Is it not x86-64 (AMD64) ?
>> <
>>> The 387 instructions were already available on IA-32.
>>>
>>> x86-64 is an older name for AMD64.
>> <
>> You don't name a baby "bob" and then years later reman him "joe"
>> <
>
> Proper solution is to glue both names together and call him "Joe-Bob".
>
>
>
> But, one could be like, "By IA-32, do you really mean iAPX 386?..."
>
> Or, debate between the relative merits of AMD64, Intel64, or EM64T.
>
> I mostly prefer the names x86-64 or x64 myself...
>
>
> Meanwhile, I will need to come up with (at some point) a different name
> for my ISA, because I am getting tired of my existing ISA name sometimes
> triggering content filtering and similar.
>
> But, existing name probably has more "recognition", and most other names
> I can come up clash with various other stuff in a search engine (such as
> "shoe insoles", sports teams, airports, ...).
>
>
>>>>> registers (80 bits wide), and they have xmm/ymm/zmm registers, which
>>>>> can contain 32-bit or 64-bit FP numbers. The 387 part has the option
>>>>> to limit the mantissa to 53 or 24 bits, which is almost, but not quite
>>>>> bit-compatible with what you get with xmm/ymm/zmm. AFAIK you get a
>>>>> difference if the 16-bit 387 exponent is outside the range supported
>>>>> by the 32-bit or 64-bit FP numbers; e.g., you may get a denormal, 0,
>>>>> or infinity in xmm where you get a normal float on the 387.
>>>>>
>>>>> AFAIK that is not a problem with reproducability in compilers, because
>>>>> they use the same feature for a given source-level operation, rather
>>>>> than choosing arbitrarily.
>>> What is a problem in compilers is the conversion that happens when
>>> storing a 387 register with a 53-bit mantissa to a 64-bit location in
>>> memory on spilling. What was a nomal number while it was in a
>>> register may become an infinity, denormal, or 0.
>>>>> However, in the early days of Java the 387 behaviour was a problem for
>>>>> the write-once-run-everywhere promise of Java. The introduction of
>>>>> SSE2 solved it.
>>>> <
>>>> This is a problem with the way Java defined FP not in x87.
>> <
>>> Java defined IEEE 754, and all other architectures provided that, but
>>> 387 didn't quite (although it was very close). And IIRC even if you
>>> stored the values to memory after every operation, you still could run
>>> into double-rounding problems.
>> <
>> Would if have been possible for java to define FP calculations in a way
>> that x87 would have been acceptable as was ?
>> <
>> If so, why was this not done ?
>
> It is a mystery...
>
> Somehow, I hadn't really thought about "What if x87 wasn't really
> IEEE-754?", as probably for many, x87 was the prototypical concept of
> what an FPU *was*.
>
>
> Then started wondering whether the N64's FPU would have been considered
> IEEE-754.
>
> Some stuff I read said it used DAZ/FTZ and Truncate rounding.
>
> However, the CPU was apparently running on a MIPS R4000 variant (R4300),
> and the FPU is said to be complaint with IEEE 754-1985.
>
> I am guessing either:
>   Something doesn't add up here;
>     My information is wrong.
>   It was done for cost-cutting and/or performance reasons?...
>     Say, if the FPU was faster if used in this mode?...
>     Or, if proper IEEE-754 wasn't required in a game console?...
>       (And, it was intended to be a bit cheaper than an SGI workstation)
>     ...
>
> Mysteries...
>

Looks into it a little more:

Turns out the R4300 in the N64 did have rounding-modes / ..., it was
more just a common emulator issue to not bother with respecting the
rounding-modes, sometimes leading to issues if the behavior was
different from what the N64 game specified (with the games primarily
operating on single-precision values).

The other one was more because apparently the CPU relied on raising an
interrupt to deal with denormal numbers (unless apparently a flag was
set which caused DAZ/FTZ behavior instead), and the response from N64
programmers was typically to set this flag (with the interrupt usually
crashing the game or similar if triggered).

Apparently the issue is that a lot of the emulators didn't respect this
behavior either, typically using whatever the host processor produces
(eg: using denormals), rather than either respecting the flag or raising
an interrupt (if the flag was not set).

Or, at least, this is what I could gather by skimming stuff talking
about it.

I guess that this implies that some of this is "not entirely invisible".

>
>
> Well, and another recent mystery:
> Why has Windows Update seemingly broken my ability to get audio output
> from the rear "Speakers" port on my PC?...
>
> But, it appears to have been a semi-common problem with this update:
> Windows Update nukes the Realtek driver, installs MS driver in its place;
> Stuff doesn't quite work correctly anymore (broken speakers/microphone);
> Apparently, for people that have tried manually reinstalling the Realtek
> drivers, Windows auto-deletes the driver files.
>
> ( Makes me half wonder if Realtek got on MS's bad side or something?...
> Didn't see any news about Realtek doing anything "shady" or similar
> though that would explain this. )
>
>
> But, can still sorta get audio out of the front-panel connector, which
> is probably "good enough" for right now.
>

Still not sure what is going on here...

>
>>>
>>> -anton
>>> --
>>> 'Anyone trying for "industrial quality" ISA should avoid undefined
>>> behavior.'
>>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>
>

Re: Mixed EGU/EGO floating-point

<3f57fe6b-873f-4932-a807-2518dc1fcf8dn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25416&group=comp.arch#25416

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:4e8f:0:b0:2f3:d216:1002 with SMTP id 15-20020ac84e8f000000b002f3d2161002mr22143815qtp.380.1652837467290;
Tue, 17 May 2022 18:31:07 -0700 (PDT)
X-Received: by 2002:a05:6808:6d7:b0:325:67ff:a21b with SMTP id
m23-20020a05680806d700b0032567ffa21bmr11689656oih.105.1652837467066; Tue, 17
May 2022 18:31:07 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!pasdenom.info!nntpfeed.proxad.net!feeder1-1.proxad.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 17 May 2022 18:31:06 -0700 (PDT)
In-Reply-To: <25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:5f1:ed53:85c4:f791;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:5f1:ed53:85c4:f791
References: <t5qe8t$fh0$1@dont-email.me> <memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de> <2022May16.114735@mips.complang.tuwien.ac.at>
<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com> <2022May16.222811@mips.complang.tuwien.ac.at>
<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3f57fe6b-873f-4932-a807-2518dc1fcf8dn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Wed, 18 May 2022 01:31:07 +0000
Content-Type: text/plain; charset="UTF-8"
 by: Quadibloc - Wed, 18 May 2022 01:31 UTC

On Monday, May 16, 2022 at 3:25:52 PM UTC-6, MitchAlsup wrote:
> On Monday, May 16, 2022 at 3:39:46 PM UTC-5, Anton Ertl wrote:
> > MitchAlsup <Mitch...@aol.com> writes:
> > >On Monday, May 16, 2022 at 5:00:58 AM UTC-5, Anton Ertl wrote:
> > >> >Sounds like a broken design to me. What exactly were the different
> > >> >kinds of FP registers, and how were they different?
> > ><
> > >> One example that comes to my mind is IA-32/AMD64. They have the 387
> > ><
> > >Is it not x86-64 (AMD64) ?
> <
> > The 387 instructions were already available on IA-32.
> >
> > x86-64 is an older name for AMD64.
> <
> You don't name a baby "bob" and then years later reman him "joe"

It's not like a computer architecture has feelilngs that could be hurt
by doing so.

John Savard

Re: Mixed EGU/EGO floating-point

<b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25417&group=comp.arch#25417

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:5dcc:0:b0:2f3:d8d2:7cf with SMTP id e12-20020ac85dcc000000b002f3d8d207cfmr22349471qtx.464.1652837706407;
Tue, 17 May 2022 18:35:06 -0700 (PDT)
X-Received: by 2002:a05:6830:928:b0:606:4f3c:d19a with SMTP id
v40-20020a056830092800b006064f3cd19amr9395569ott.58.1652837706109; Tue, 17
May 2022 18:35:06 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 17 May 2022 18:35:05 -0700 (PDT)
In-Reply-To: <t60uh1$o8s$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:5f1:ed53:85c4:f791;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:5f1:ed53:85c4:f791
References: <t5qe8t$fh0$1@dont-email.me> <memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de> <2022May16.114735@mips.complang.tuwien.ac.at>
<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com> <2022May16.222811@mips.complang.tuwien.ac.at>
<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com> <t5v565$9s4$1@dont-email.me>
<t60uh1$o8s$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Wed, 18 May 2022 01:35:06 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2150
 by: Quadibloc - Wed, 18 May 2022 01:35 UTC

On Tuesday, May 17, 2022 at 1:54:13 PM UTC-6, BGB wrote:
> On 5/16/2022 10:35 PM, BGB wrote:

> > ( Makes me half wonder if Realtek got on MS's bad side or something?...
> > Didn't see any news about Realtek doing anything "shady" or similar
> > though that would explain this. )

> Still not sure what is going on here...

No malice need be suspected when Microsoft being clumsy and
stupid and releasing updates without adequate testing, like they've
done how many times before, is sufficient.

Although, that may be unfair to Microsoft, as the number of possible
devices and drivers for Windows PCs is... large. This isn't the closed
Apple ecosystem.

John Savard

Re: Mixed EGU/EGO floating-point

<t61j77$s7e$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25418&group=comp.arch#25418

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Tue, 17 May 2022 20:47:18 -0500
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <t61j77$s7e$1@dont-email.me>
References: <t5qe8t$fh0$1@dont-email.me>
<memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de>
<2022May16.114735@mips.complang.tuwien.ac.at>
<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>
<2022May16.222811@mips.complang.tuwien.ac.at>
<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
<t5v565$9s4$1@dont-email.me> <t60uh1$o8s$1@dont-email.me>
<b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 18 May 2022 01:47:20 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="65abca4d26331c3457a4e36355643824";
logging-data="28910"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18VVlxL1vb047VQN/drzNyC"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:KrQzG/ID3WYcybuDyqjURzx4NFg=
In-Reply-To: <b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
Content-Language: en-US
 by: BGB - Wed, 18 May 2022 01:47 UTC

On 5/17/2022 8:35 PM, Quadibloc wrote:
> On Tuesday, May 17, 2022 at 1:54:13 PM UTC-6, BGB wrote:
>> On 5/16/2022 10:35 PM, BGB wrote:
>
>>> ( Makes me half wonder if Realtek got on MS's bad side or something?...
>>> Didn't see any news about Realtek doing anything "shady" or similar
>>> though that would explain this. )
>
>> Still not sure what is going on here...
>
> No malice need be suspected when Microsoft being clumsy and
> stupid and releasing updates without adequate testing, like they've
> done how many times before, is sufficient.
>
> Although, that may be unfair to Microsoft, as the number of possible
> devices and drivers for Windows PCs is... large. This isn't the closed
> Apple ecosystem.
>

Possible, though having the OS automatically delete drivers and then
refuse to let them be reinstalled by end users would seemingly imply
that "something" is going on here (as opposed to it being a normal
software bug).

> John Savard

Re: Mixed EGU/EGO floating-point

<fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25420&group=comp.arch#25420

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:528e:b0:45a:95ff:337f with SMTP id kj14-20020a056214528e00b0045a95ff337fmr23077623qvb.78.1652839128932;
Tue, 17 May 2022 18:58:48 -0700 (PDT)
X-Received: by 2002:aca:e155:0:b0:325:6d76:da4b with SMTP id
y82-20020acae155000000b003256d76da4bmr12601583oig.125.1652839128689; Tue, 17
May 2022 18:58:48 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 17 May 2022 18:58:48 -0700 (PDT)
In-Reply-To: <b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:b906:a655:bfcf:bf2f;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:b906:a655:bfcf:bf2f
References: <t5qe8t$fh0$1@dont-email.me> <memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de> <2022May16.114735@mips.complang.tuwien.ac.at>
<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com> <2022May16.222811@mips.complang.tuwien.ac.at>
<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com> <t5v565$9s4$1@dont-email.me>
<t60uh1$o8s$1@dont-email.me> <b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 18 May 2022 01:58:48 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2553
 by: MitchAlsup - Wed, 18 May 2022 01:58 UTC

On Tuesday, May 17, 2022 at 8:35:07 PM UTC-5, Quadibloc wrote:
> On Tuesday, May 17, 2022 at 1:54:13 PM UTC-6, BGB wrote:
> > On 5/16/2022 10:35 PM, BGB wrote:
>
> > > ( Makes me half wonder if Realtek got on MS's bad side or something?...
> > > Didn't see any news about Realtek doing anything "shady" or similar
> > > though that would explain this. )
> > Still not sure what is going on here...
> No malice need be suspected when Microsoft being clumsy and
> stupid and releasing updates without adequate testing,
<
like they've done how many times before
<
Has MS EVER released a product AFTER adequate testing has been applied ?
<
> , is sufficient.
>
> Although, that may be unfair to Microsoft, as the number of possible
> devices and drivers for Windows PCs is... large. This isn't the closed
> Apple ecosystem.
<
Not that Apple has that stellar of a record........
>
> John Savard

Re: Mixed EGU/EGO floating-point

<4aa69351-6b39-472f-80d0-742e1a9a4dddn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25423&group=comp.arch#25423

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:5aa8:0:b0:45a:f1e4:7b24 with SMTP id u8-20020ad45aa8000000b0045af1e47b24mr282097qvg.127.1652891061325;
Wed, 18 May 2022 09:24:21 -0700 (PDT)
X-Received: by 2002:a05:6808:16ac:b0:2f9:52e5:da90 with SMTP id
bb44-20020a05680816ac00b002f952e5da90mr451484oib.5.1652891061097; Wed, 18 May
2022 09:24:21 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Wed, 18 May 2022 09:24:20 -0700 (PDT)
In-Reply-To: <fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:6947:3c86:73e1:a64e;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:6947:3c86:73e1:a64e
References: <t5qe8t$fh0$1@dont-email.me> <memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de> <2022May16.114735@mips.complang.tuwien.ac.at>
<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com> <2022May16.222811@mips.complang.tuwien.ac.at>
<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com> <t5v565$9s4$1@dont-email.me>
<t60uh1$o8s$1@dont-email.me> <b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
<fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4aa69351-6b39-472f-80d0-742e1a9a4dddn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Wed, 18 May 2022 16:24:21 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1953
 by: Quadibloc - Wed, 18 May 2022 16:24 UTC

On Tuesday, May 17, 2022 at 7:58:50 PM UTC-6, MitchAlsup wrote:

> Has MS EVER released a product AFTER adequate testing has been applied ?

PC-DOS 1.0? Paper-tape BASIC for the Altair? Otherwise, I can't _think_ of
any examples offhand, but I didn't want to go too far, in case I might be
accused of bias against Microsoft.

John Savard

Re: Mixed EGU/EGO floating-point

<t64kbq$r9q$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25424&group=comp.arch#25424

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Thu, 19 May 2022 00:25:11 -0500
Organization: A noiseless patient Spider
Lines: 104
Message-ID: <t64kbq$r9q$1@dont-email.me>
References: <t5qe8t$fh0$1@dont-email.me>
<memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de>
<2022May16.114735@mips.complang.tuwien.ac.at>
<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>
<2022May16.222811@mips.complang.tuwien.ac.at>
<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
<t5v565$9s4$1@dont-email.me> <t60uh1$o8s$1@dont-email.me>
<b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
<fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com>
<4aa69351-6b39-472f-80d0-742e1a9a4dddn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 19 May 2022 05:25:14 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="94e4a6a741234d1c6937dbe6aba2df81";
logging-data="27962"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX182zghYcyEzt4p8VPHHmOT8"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:85jUGhcxoUHibEhwqZUmAkXAycI=
In-Reply-To: <4aa69351-6b39-472f-80d0-742e1a9a4dddn@googlegroups.com>
Content-Language: en-US
 by: BGB - Thu, 19 May 2022 05:25 UTC

On 5/18/2022 11:24 AM, Quadibloc wrote:
> On Tuesday, May 17, 2022 at 7:58:50 PM UTC-6, MitchAlsup wrote:
>
>> Has MS EVER released a product AFTER adequate testing has been applied ?
>
> PC-DOS 1.0? Paper-tape BASIC for the Altair? Otherwise, I can't _think_ of
> any examples offhand, but I didn't want to go too far, in case I might be
> accused of bias against Microsoft.
>

Some more fiddling later, I am not thinking yeah, maybe it is actually
due to a bug...

Still annoying though, but at least I have a partial workaround.

Well, in my case, I still have enough of my own bugs.

Spent a while trying to hunt down a remaining bug in my CPU core, and
eventually did find something:
If SP or DLR was being modified from Lanes 2 or 3, and an interrupt
happened, then there was a chance that the wrong state of the variable
could be captured due to the relevant forwarding logic either failing to
check these lanes (SP), or always capturing the "current" version of DLR
(which was not necessarily the version in effect during the time the
instruction at that stage of the pipeline was executed, *...).

Adding some logic to deal with these, and the issue "appears" to have
gone away (at least for now), but, sadly, these bugs going away doesn't
necessarily mean they wont come back later.

So, like, hopefully I got it this time, but I guess I will know based on
whether or not it shows up again later.

*: For being able to correctly resume at a given instruction, it being
necessary to restore the state to what it was at the time a given
instruction was issued, which is more of an issue for "special"
registers with "side channels" than for the other GPRs (where flushing
the pipeline stages effectively prevents them from being written back to
the register file).
(I guess, "better" here would been to avoid having any registers with
side-channel updates, though this would have meant needing to have
designed the ISR mechanism and a few other things differently).

The extra forwarding logic for this fixed did add LUT cost though.

While I was messing with it, took an aside and implemented another feature:
A little while ago, I implemented a 64-bit integer multiply/divide unit;
Then I had added FDIV, but it was slow;
Then I decided to try feeding FDIV through the 64-bit integer divider,
with a few hacks to allow it to deal with Binary64.

And, well, it appears to work:
Can do an FDIV in 122 cycles (a lot faster than the other one);
Was able to get it to produce a "correct" output.
After rounding, results tend to be accurate down to the ULP.

It basically pulls off the FDIV by dividing the mantissas and running
the divider for longer, which effectively shifts the decimal point left
and generates more low-order bits. I can then grab the mantissa from the
result.

Theoretically, a very similar hack could be used for FMUL, but is
unnecessary (would be pointlessly slow; albeit would have the merit of
not requiring the use of DSP blocks).

Not sure if this falls into "clever hack" territory, of is something
that "should be obvious". Granted, the logic inside this MUL/DIV unit is
a little convoluted, so feeding Binary64 FDIV through it (by hacking the
integer divider) seems almost a little arcane.

When this case is enabled, it just sorta reroutes the FDIV through this
unit. Still leaves the prior logic (in the FPU) to deal with FSQRT, but
at the moment, can't think of any way to trick a shift-subtract divider
into calculating a square-root.

....

Did look at code some more:
FEii_iiii_7wnm_ZeiZ //Imm29s
FEii_iiii_9wnm_Zeii //Imm33s

Should decode as expected in the Verilog (no changes were needed in this
case, they should probably decode correctly as-is).

I had now added code for decoding these cases to my emulator as well;
but will still need to add compiler support for these encodings (so that
it will be able to emit them).

These would mostly allow for things like:
ADD R43, 0x12345678, R39

To be able to be encoded within a single instruction.

....

Re: Mixed EGU/EGO floating-point

<h5sd8h101hrvn111rh5lc6s29plmb9g8e0@4ax.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25425&group=comp.arch#25425

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: gneun...@comcast.net (George Neuner)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Thu, 19 May 2022 21:42:47 -0400
Organization: A noiseless patient Spider
Lines: 10
Message-ID: <h5sd8h101hrvn111rh5lc6s29plmb9g8e0@4ax.com>
References: <memo.20220515153920.11824J@jgd.cix.co.uk> <t5rco4$ga5$1@newsreader4.netcologne.de> <2022May16.114735@mips.complang.tuwien.ac.at> <60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com> <2022May16.222811@mips.complang.tuwien.ac.at> <25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com> <t5v565$9s4$1@dont-email.me> <t60uh1$o8s$1@dont-email.me> <b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com> <fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="def0d4f6961b9847261b5e1b80e6569c";
logging-data="23703"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/tCB1ksXKxDSJJc16QQWQtdJjmFS0jl8M="
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha1:SLnI9zUNXGUbjWgXQ/OKInx5RMY=
 by: George Neuner - Fri, 20 May 2022 01:42 UTC

On Tue, 17 May 2022 18:58:48 -0700 (PDT), MitchAlsup
<MitchAlsup@aol.com> wrote:

>Has MS EVER released a product AFTER adequate testing has been applied ?

According to the book by Steve Macguire, Excel was extensively tested.
Macguire worked for Microsoft, so you can make of that what you will.

George

Re: Mixed EGU/EGO floating-point

<4b331c41-b15c-4719-897a-a0256f2f000dn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25426&group=comp.arch#25426

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:4104:b0:42c:1db0:da28 with SMTP id kc4-20020a056214410400b0042c1db0da28mr6261042qvb.67.1653013281677;
Thu, 19 May 2022 19:21:21 -0700 (PDT)
X-Received: by 2002:a05:6870:b01e:b0:f1:ea32:181d with SMTP id
y30-20020a056870b01e00b000f1ea32181dmr4406302oae.126.1653013281423; Thu, 19
May 2022 19:21:21 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 19 May 2022 19:21:21 -0700 (PDT)
In-Reply-To: <h5sd8h101hrvn111rh5lc6s29plmb9g8e0@4ax.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:1d1e:f9c3:acbf:fd2a;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:1d1e:f9c3:acbf:fd2a
References: <memo.20220515153920.11824J@jgd.cix.co.uk> <t5rco4$ga5$1@newsreader4.netcologne.de>
<2022May16.114735@mips.complang.tuwien.ac.at> <60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>
<2022May16.222811@mips.complang.tuwien.ac.at> <25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
<t5v565$9s4$1@dont-email.me> <t60uh1$o8s$1@dont-email.me> <b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
<fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com> <h5sd8h101hrvn111rh5lc6s29plmb9g8e0@4ax.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4b331c41-b15c-4719-897a-a0256f2f000dn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Fri, 20 May 2022 02:21:21 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3524
 by: MitchAlsup - Fri, 20 May 2022 02:21 UTC

On Thursday, May 19, 2022 at 8:42:53 PM UTC-5, George Neuner wrote:
> On Tue, 17 May 2022 18:58:48 -0700 (PDT), MitchAlsup
> <Mitch...@aol.com> wrote:
>
>
> >Has MS EVER released a product AFTER adequate testing has been applied ?
> According to the book by Steve Macguire, Excel was extensively tested.
> Macguire worked for Microsoft, so you can make of that what you will.
>
> George
<
Extensive testing may still be inadequate.
<
I was brought in as a consultant (1992) to figure out why a design was taking so
long to debug. After only a couple of weeks I put my finger on the issue. There
were 2 large state machines, each one governing one aspect of cache coherence
{one the cache looking out at the system and system looking at the current state
of the cache.}
<
Each state machine required ~100,000 test vectors, but together they required
10,000,000,000 test vectors !! the cartesian product of all the states both machines
could be in. {100,000 test vectors is a completely reasonable number when you
consider power-on-reset sequences, various modes (boot, normal, power down)
and general use (typically less than 30% of testing).
<
After a little research into what each machine was doing, it became obvious that
the reduction of 5% of the states in each machine could drop the test vector set
into the 1,000,000 range with a corresponding loss of less than 2% in perf. This
reduced tester time from several minutes to about 5 seconds (on a machine worth
$100,000/day)
<
One could have tested the original part for nearly a year before KNOWING that is
was bug free, whereas after being fixed it took but seconds.
<
Extensive testing where every state machine gets to make all of its own choices
independently, leads to the reason I was hired as a consultant--and that extensive
testing remains IN-adequate !! OoO programming is of the former..........

Re: Mixed EGU/EGO floating-point

<122ce6ce-0907-4181-bd3b-0cc9eadf2446n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25427&group=comp.arch#25427

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:7f01:0:b0:2f9:cdc:ca4f with SMTP id f1-20020ac87f01000000b002f90cdcca4fmr6353796qtk.345.1653013938482;
Thu, 19 May 2022 19:32:18 -0700 (PDT)
X-Received: by 2002:a05:6808:13d6:b0:326:c5b0:14c2 with SMTP id
d22-20020a05680813d600b00326c5b014c2mr4330593oiw.37.1653013938291; Thu, 19
May 2022 19:32:18 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 19 May 2022 19:32:18 -0700 (PDT)
In-Reply-To: <4b331c41-b15c-4719-897a-a0256f2f000dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:6947:3c86:73e1:a64e;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:6947:3c86:73e1:a64e
References: <memo.20220515153920.11824J@jgd.cix.co.uk> <t5rco4$ga5$1@newsreader4.netcologne.de>
<2022May16.114735@mips.complang.tuwien.ac.at> <60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>
<2022May16.222811@mips.complang.tuwien.ac.at> <25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
<t5v565$9s4$1@dont-email.me> <t60uh1$o8s$1@dont-email.me> <b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
<fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com> <h5sd8h101hrvn111rh5lc6s29plmb9g8e0@4ax.com>
<4b331c41-b15c-4719-897a-a0256f2f000dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <122ce6ce-0907-4181-bd3b-0cc9eadf2446n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Fri, 20 May 2022 02:32:18 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2417
 by: Quadibloc - Fri, 20 May 2022 02:32 UTC

On Thursday, May 19, 2022 at 8:21:23 PM UTC-6, MitchAlsup wrote:
> On Thursday, May 19, 2022 at 8:42:53 PM UTC-5, George Neuner wrote:
> > On Tue, 17 May 2022 18:58:48 -0700 (PDT), MitchAlsup
> > <Mitch...@aol.com> wrote:

> > >Has MS EVER released a product AFTER adequate testing has been applied ?

> > According to the book by Steve Macguire, Excel was extensively tested.
> > Macguire worked for Microsoft, so you can make of that what you will.

> Extensive testing may still be inadequate.

This is true. But since Excel is an _application_, as opposed to an _operating system_,
the problem of testing it adequately is not necessarily as impossible as the problem of
testing a Windows Update.

John Savard

Re: Mixed EGU/EGO floating-point

<t67cg5$emp$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=25428&group=comp.arch#25428

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Fri, 20 May 2022 01:29:22 -0500
Organization: A noiseless patient Spider
Lines: 108
Message-ID: <t67cg5$emp$1@dont-email.me>
References: <memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de>
<2022May16.114735@mips.complang.tuwien.ac.at>
<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>
<2022May16.222811@mips.complang.tuwien.ac.at>
<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
<t5v565$9s4$1@dont-email.me> <t60uh1$o8s$1@dont-email.me>
<b3f3d17e-aca8-4a86-85bd-2fd1ab798d6fn@googlegroups.com>
<fc10c937-966d-4247-9636-c8b1dae337c0n@googlegroups.com>
<h5sd8h101hrvn111rh5lc6s29plmb9g8e0@4ax.com>
<4b331c41-b15c-4719-897a-a0256f2f000dn@googlegroups.com>
<122ce6ce-0907-4181-bd3b-0cc9eadf2446n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 20 May 2022 06:29:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="756b597d733c76eaf507e082708a7aad";
logging-data="15065"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+pnzrMqgyUFfwD4OT+tEQk"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:tEhiELsc1vj9WD4YhPsqZ2ecP2Q=
In-Reply-To: <122ce6ce-0907-4181-bd3b-0cc9eadf2446n@googlegroups.com>
Content-Language: en-US
 by: BGB - Fri, 20 May 2022 06:29 UTC

On 5/19/2022 9:32 PM, Quadibloc wrote:
> On Thursday, May 19, 2022 at 8:21:23 PM UTC-6, MitchAlsup wrote:
>> On Thursday, May 19, 2022 at 8:42:53 PM UTC-5, George Neuner wrote:
>>> On Tue, 17 May 2022 18:58:48 -0700 (PDT), MitchAlsup
>>> <Mitch...@aol.com> wrote:
>
>>>> Has MS EVER released a product AFTER adequate testing has been applied ?
>
>>> According to the book by Steve Macguire, Excel was extensively tested.
>>> Macguire worked for Microsoft, so you can make of that what you will.
>
>> Extensive testing may still be inadequate.
>
> This is true. But since Excel is an _application_, as opposed to an _operating system_,
> the problem of testing it adequately is not necessarily as impossible as the problem of
> testing a Windows Update.
>

Debugging program code is a lot easier in general, since its state often
reduces down more easily to a binary choice of "works" or "doesn't work".

One can generally look at the state of the program, when and where it
misbehaves, and figure out what went wrong and why.

Vs, say, bugs which appear and then disappear, and then reappear later
if the wind blows just the right way, then disappear again when one
pokes at things, ...

At this point of development, a lot of the bugs I am facing more fall
into this category.

I also have some old crufty hacks, with comments like "TODO: figure out
what is going going on here." Some of these cases are things I never
figured out.

Eg: There is a hack to detect if a branch immediately follows a memory
operation, and if so to insert a pipeline interlock. Why? Because, for
whatever reason, if a branch immediately follows a memory operation,
then the branch may fail to execute.

If I try to disable this hack, it triggers a sanity check in the boot
ROM, because after I found this bug originally, I put in a sanity check
which triggers if this bug reappears (showing that the bug still exists).

These kinda hacks are a bit tacky though.

Or the causes are something obscure, a few recent examples:
Interrupt initiates, TLB disables itself, but a request that "should
miss" is still on the bus;
Interrupt initiates, but an in-progress memory request ends up being
handled on the ISR's part of the address space vs in the applications'
part of the address space;
Interrupt initiates, but there was an "ADD Imm, SP" instruction in Lane
2 which is lost because the forwarding logic for capturing the state of
SP on an interrupt entry failed to check for SP updates in Lanes 2 or 3
(naively assuming that no one would update SP from Lane 2 or 3).

....

Then to the outside world, it seems like I have probably not been doing
anything, because no major features are getting added, mostly just me
beating on stuff trying to look for bugs.

It starts to seem almost like to "fully" debug this stuff, one might
almost need to basically do a "feature freeze" and then spend nearly all
of their time basically debugging, but this is kinda lame.

Adding new features is nice, but this shakes up bugs.

Though, OTOH, "poking the bees nest" might also help point out bugs that
might have been missed, whereas a "feature freeze" might have
effectively hidden the bugs from view. So it is a tradeoff.

In any case, there are seemingly a lot more cases than what can be
tested adequately in a few K of code in the Boot ROM.

OTOH, After I had gone through a bunch of effort trying to squeeze size
out of the Boot ROM, I had discovered another compiler bug:
If Jumbo encodings were enabled, then the compiler would also try to do
WEX bundling stuff even if it was set to size optimization. I then added
some code to disable it trying to use WEX if the compiler was set to
size-optimization mode, which shaved ~ 17% off the size of the Boot ROM.

Trying to add a trick to shuffle 3AC ops in the compiler to reduce
dependencies "sorta worked"; I did see a slight improvement to
performance in Doom and similar (and a slight increase in the number of
bundled instructions), but it was also prone to causing stuff to be more
crash-prone (and seemingly had no real effect on Quake or similar, and
seemingly caused Dhrystone to get slower).

I disabled it again, it is another one of those features I may need to
debug more later (but I was already hunting enough bugs already, without
adding more bugs to the mix).

....

> John Savard

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor