Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

How many chunks could checkchunk check if checkchunk could check chunks? -- Alan Cox


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

<2022May16.095507@mips.complang.tuwien.ac.at>

 copy mid

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

 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: Mon, 16 May 2022 07:55:07 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 41
Distribution: world
Message-ID: <2022May16.095507@mips.complang.tuwien.ac.at>
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>
Injection-Info: reader02.eternal-september.org; posting-host="128a42e0247b02702bd84c94989e66d3";
logging-data="29109"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18BwyA744imV6loi7U2ScOc"
Cancel-Lock: sha1:s1GkLCNXa+cun3p0ZLM4Lspder4=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 16 May 2022 07:55 UTC

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". Show assembly code produced for the
Fortran code above, and show that it is much better than the code
produced for

s = sum(a)

(which Terje Mathiesen would do for computing the same result, if FP
numbers had the "none" value he asked for)

>As for "instruction" - well, it need
>not be an actual machine instruction in an ISA, it could also be
>a statement in a language.

We are in comp.arch, so ISA and microinstructions are what matters
here. Programming languages have arbitrarily complex concepts, and
can express things concisely that are expensive to evaluate. Showing
some high-level code is, in general, not sufficient for evaluating an
architectural feature.

- 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

<2022May16.114735@mips.complang.tuwien.ac.at>

 copy mid

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

 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: Mon, 16 May 2022 09:47:35 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 31
Distribution: world
Message-ID: <2022May16.114735@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>
Injection-Info: reader02.eternal-september.org; posting-host="128a42e0247b02702bd84c94989e66d3";
logging-data="3775"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ZxBU67hch7aEqSkh+ab7M"
Cancel-Lock: sha1:CbnHX+ESC4NQsOAakSdEDIxhk80=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 16 May 2022 09:47 UTC

Thomas Koenig <tkoenig@netcologne.de> writes:
>John Dallman <jgd@cix.co.uk> schrieb:
>> It is. A manufacturer once told us we could not expect bit-identical
>> results between two different kinds of FP registers on the same machine,
>> both usable at the same time. For ISVs who use compilers, rather than
>> assembler, that's deadly.
>
>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
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.

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.

- 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

<t5tps3$5u2$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Mon, 16 May 2022 08:16:18 -0700
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <t5tps3$5u2$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> <hf9gK.27170$6dof.15166@fx13.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 16 May 2022 15:16:19 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="d9eaeed0415b01b17aae9e503ef5e66e";
logging-data="6082"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18R5kc+nVyUV1jIAhx5pAAN9v38u/8yi2I="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:20TerNjgoBMzZR8218+wcs04Z+s=
In-Reply-To: <hf9gK.27170$6dof.15166@fx13.iad>
Content-Language: en-US
 by: Stephen Fuld - Mon, 16 May 2022 15:16 UTC

On 5/15/2022 8:46 AM, EricP wrote:
> Thomas Koenig wrote:
>> Anton Ertl <anton@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.
>>
>> Simply ignoring values for summation would start leading to
>> "interesting" results when you want to have an average instead of
>> a sum, for example.
>>
>> Introducing new classes of numbers in floating point is no substitute
>> for careful thought on part of the programmer.
>
> None/Null missing values occur all the time in datasets.
> Applications that can have missing values already deal with this.
> Currently they just all deal with it individually.
>
> It might be nice to standardize the behavior.
>
> For example, how should compare operators > >= < <=
> work for different values of left and right operands,
> so that it makes sense for Min(a,b) and Max(a,b).

You might want to look at DB2 (IBM's relational database software). It
has supported missing values, called "Nulls", for decades, and it
supports what are called aggregate functions such as sum, max, count,
etc. Note also that Nulls are supported for all types of data, not just
floating point. And no, I don't know what value(s) they use for null. :-(

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Mixed EGU/EGO floating-point

<fvvgK.874$6XNb.513@fx07.iad>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx07.iad.POSTED!not-for-mail
From: ThatWoul...@thevillage.com (EricP)
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
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> <hf9gK.27170$6dof.15166@fx13.iad> <t5tps3$5u2$1@dont-email.me>
In-Reply-To: <t5tps3$5u2$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 62
Message-ID: <fvvgK.874$6XNb.513@fx07.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Mon, 16 May 2022 17:05:15 UTC
Date: Mon, 16 May 2022 13:03:10 -0400
X-Received-Bytes: 3127
 by: EricP - Mon, 16 May 2022 17:03 UTC

Stephen Fuld wrote:
> On 5/15/2022 8:46 AM, EricP wrote:
>> Thomas Koenig wrote:
>>> Anton Ertl <anton@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.
>>>
>>> Simply ignoring values for summation would start leading to
>>> "interesting" results when you want to have an average instead of
>>> a sum, for example.
>>>
>>> Introducing new classes of numbers in floating point is no substitute
>>> for careful thought on part of the programmer.
>>
>> None/Null missing values occur all the time in datasets.
>> Applications that can have missing values already deal with this.
>> Currently they just all deal with it individually.
>>
>> It might be nice to standardize the behavior.
>>
>> For example, how should compare operators > >= < <=
>> work for different values of left and right operands,
>> so that it makes sense for Min(a,b) and Max(a,b).
>
> You might want to look at DB2 (IBM's relational database software). It
> has supported missing values, called "Nulls", for decades, and it
> supports what are called aggregate functions such as sum, max, count,
> etc. Note also that Nulls are supported for all types of data, not just
> floating point. And no, I don't know what value(s) they use for null. :-(

Yes, for compare operations SQL's NULL handling
could be a good starting point.

But SQL's arithmetic defines that any expression with a null
operand is null, which does not sound like what people might want.
It sounded like "Value + Null => Value" is what was proposed.

Note that SQL uses trinary logic value (True, False, Unknown)
so in addition to usual boolean operations you have

NOT U => U

U OR F => U
U OR T => T
U OR U => U

U AND F => F
U AND T => U
U AND U => U

Unlike 754 Nan's, all compare operators to Null value
return Unknown not False, including <> (not equal).
IS NULL and IS NOT NULL test for null values.

Re: Mixed EGU/EGO floating-point

<t5u0uj$273j$1@gal.iecc.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: joh...@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Mon, 16 May 2022 17:17:07 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <t5u0uj$273j$1@gal.iecc.com>
References: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com> <t5r53e$cjh$1@newsreader4.netcologne.de> <hf9gK.27170$6dof.15166@fx13.iad> <t5tps3$5u2$1@dont-email.me>
Injection-Date: Mon, 16 May 2022 17:17:07 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="72819"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <de735513-d303-42b6-b375-916b89ddafcan@googlegroups.com> <t5r53e$cjh$1@newsreader4.netcologne.de> <hf9gK.27170$6dof.15166@fx13.iad> <t5tps3$5u2$1@dont-email.me>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Mon, 16 May 2022 17:17 UTC

According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>You might want to look at DB2 (IBM's relational database software). It
>has supported missing values, called "Nulls", for decades, and it
>supports what are called aggregate functions such as sum, max, count,
>etc. Note also that Nulls are supported for all types of data, not just
>floating point. And no, I don't know what value(s) they use for null. :-(

That's how SQL works, so other SQL databases like PostgreSQL and MySQL
and MS SQL server handle nulls, too.

Dunno what DB2 does for nulls but MySQL keeps a bit map external to
the data, so there are no reserved values. You can null any kind of
field including strings and decimal numbers. The AVG() function
excludes nulls, other functions ignore them when aggregating, pass
them through otherwise.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Mixed EGU/EGO floating-point

<bcfb3ec9-83df-4e61-8edf-f80f4d3fe7d0n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:5b96:0:b0:2f8:af64:a0bd with SMTP id a22-20020ac85b96000000b002f8af64a0bdmr5534243qta.463.1652724772597;
Mon, 16 May 2022 11:12:52 -0700 (PDT)
X-Received: by 2002:a05:6830:2475:b0:605:4339:dbc9 with SMTP id
x53-20020a056830247500b006054339dbc9mr6506707otr.313.1652724772355; Mon, 16
May 2022 11:12:52 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!pasdenom.info!nntpfeed.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: Mon, 16 May 2022 11:12:52 -0700 (PDT)
In-Reply-To: <2022May16.082647@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:ed92:50fe:820d:b048;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:ed92:50fe:820d:b048
References: <de735513-d303-42b6-b375-916b89ddafcan@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>
<2022May16.082647@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <bcfb3ec9-83df-4e61-8edf-f80f4d3fe7d0n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 16 May 2022 18:12:52 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Mon, 16 May 2022 18:12 UTC

On Monday, May 16, 2022 at 1:30:19 AM UTC-5, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >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. Also note:
> >FMAX( x, -x ) is 1 instruction because My 66000 ISA has sign control over
> >operands already.
> Anything wrong with x & 0x7fffffffffffffff ?
<
Arithmetically: none;
But it takes 1 cycle whereas -x takes 0 cycles.
<
FMAX Rd,Rx,-Rx
>
> Given that you have to bear the costs of sign-magnitude, you should
> also rip the benefits.
<
That's reap (not rip).
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Re: Mixed EGU/EGO floating-point

<36e5226f-2a99-45f4-aef8-4ef75b43ceecn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:188a:b0:2f3:f4a8:ac9b with SMTP id v10-20020a05622a188a00b002f3f4a8ac9bmr16360739qtc.396.1652725805042;
Mon, 16 May 2022 11:30:05 -0700 (PDT)
X-Received: by 2002:a05:6870:d1cd:b0:e1:e7ee:faa0 with SMTP id
b13-20020a056870d1cd00b000e1e7eefaa0mr15917947oac.5.1652725804785; Mon, 16
May 2022 11:30:04 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!pasdenom.info!nntpfeed.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: Mon, 16 May 2022 11:30:04 -0700 (PDT)
In-Reply-To: <t5t2me$rh5$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:ed92:50fe:820d:b048;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:ed92:50fe:820d:b048
References: <t5qe8t$fh0$1@dont-email.me> <memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de> <t5rn0u$lsi$1@dont-email.me>
<b78d6cfa-cba6-40ca-832b-86af306de767n@googlegroups.com> <t5rum0$bu9$1@dont-email.me>
<2df555e6-2b58-4972-8fd2-87f8cace547dn@googlegroups.com> <t5t2me$rh5$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <36e5226f-2a99-45f4-aef8-4ef75b43ceecn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 16 May 2022 18:30:05 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Mon, 16 May 2022 18:30 UTC

On Monday, May 16, 2022 at 3:40:50 AM UTC-5, BGB wrote:
> On 5/15/2022 6:15 PM, MitchAlsup wrote:
> > On Sunday, May 15, 2022 at 5:26:11 PM UTC-5, BGB wrote:
>
> >> If XGPR is not enabled, we can assume that R32..R63 do not exist (and
> >> the low bit of the register for 128-bit operations is "Must Be Zero").
> > <
> > What do you do for code compiled assuming XGPR exists and you want to
> > run on THIS implementation ??
> It wont work.
>
> These scenarios are not binary compatible with each other.
>
Code compiled for one member of My 66000 will run on all members of
My 66000.
>
>
> There is not strict requirement that code built for BJX2 with one
> profile be able to run on a core built with a different profile.
>
I chose differently, so did Mill but they solved the problem differently.
>
> This is why there are "profiles".
>
> Code built for the baseline feature-set of one profile, will generally
> be expected to run on cores for the same profile. However, code build
> for the baseline of one profile will not necessarily be able to run on a
> core implementing a different profile.
>
>
> So, for example:
> XGPR is an optional feature within the 'A' profile;
> It is a baseline feature within the 'G' profile.
>
> Where:
> G: Has 64 GPRs and a 96-bit address space.
> A: Has WEX-3W, 32 GPRs, and a 48-bit address space.
> C: Has WEX-3W, 32 GPRs, and a 32-bit address space (MMU).
> F: Has FPU (scalar only) but no MMU.
> E: No FPU or MMU.
>
My 66000 does not have E or F or C or A
My 66000 only has 32×64-bit registers and 4×64-bit virtual and physical
address spaces.
>
> 'G' profile code will not run on an A profile core, and 'A' profile code
> will not run on 'F'
>
> The G profile will need something like an XC7A100T, whereas the E
> profile can fit on an XC7S25.
>
>
> However... Despite being the same ISA, they are different enough as to
> not be binary compatible with each other.
>
> 'E' and 'F' profiles being basically scalar RISC machines.
>
You get to make this poor choice.
>
------------------------
> > The compiler can save as many or as few registers between R16 and R29
> > as it desired, can save an update FP as desired, can save and restore SP
> > if desired (seldom) or just update and backdate SP as desired. If desired
> > Registers R1-R8 (arguments) can be saved--and here they get concatenated
> > with the stack passed arguments for ease of varargs.
> > <
> > So, the compiler gets to choose how many and if.
> The compiler chooses in this case as well, but the compiler is limited
> in terms of its own cleverness...
>
> One can more easily do "perfect fit" when writing ASM.
>
What ?
> >>
> >> If I enabled R32..R63 in the main C ABI:
> >> R40..R47: Enabled for very high register pressure.
> >> R56..R63: Enabled for very high register pressure.
> >> R32..R39: Enabled for very high pressure leaf functions.
> >> R48..R55: Enabled for very high pressure leaf functions.
> >>
> > <
> > With only 32 registers (1 being SP and 1 optionally being FP) I am finding
> > very little spill/fill codes, so whatever LLVM did and whatever Brian's
> > My 66000 port does, I don't seem to run into the mentioned problems.
<
> I have 32 registers, but still see a lot of spill/fill.
>
> A fair chunk of this though is because my compiler isn't smart enough to
> keep values in registers across basic blocks without statically
> assigning them to a register for the functions entire lifespan.
>
> It also "wastes" a lot of registers on things like temporaries (with
> associated RegReg MOV instructions).
<
My 66000 wastes 0 registers on constants, immediates, and displacements
{except when passing an immediate to a subroutine or initializing a register
to a constant value.}
<
> It is also prone to spilling
> temporaries to the stack even if their value will not be used again, ...
<
I am sure Brian's compiler "spills" to the stack, but more often it simply
allocated the register on the stack and processes via LDs and STs.
I see a lot of LD---op---St sequences
I see a few ST---op--op--LD sequences
<
> (Accurately determining that a temporary's value will not be used
> elsewhere is easier said than done, and "to be safe" means needing to
> spill all variables and temporaries to the stack, even if their values
> will not be used again).
<
All sorts of things are possible, I just see little of these extreme cases.
Possibly because 31 of the 31 registers are free to the compilers use
{only SP is fixed.}
>
> Doing better than this would require something akin to a "phi" operator
> (merges variables from various paths and marks which versions of the
> variable can flow into the merged variable along this path), but my past
> attempts to implement a working phi operator were not particularly
> successful.
>
LLVM intermediate has all the clues to sorting this out.
>
> I can generally do a lot better than this with hand-written ASM though.
> >>
> >> However, when not doing things like using 128-bit values for pretty much
> >> everything, then there isn't really enough register pressure for the
> >> compiler to justify enabling the higher-numbered registers.
> >>
> >> And, if enabled, a round-robin register allocation scheme will end up
> >> with nearly all of the registers being saved/restored.
> >>
> > There are some special cases you need to be aware of: simple recursive
> > functions are often faster when you do NOT allocate locals into registers
> > and just leave them on the stack. In this corner, the trade offs are rather
> > delicate.
> Potentially.
> >>
> >> Some settings may fine turn the heuristics, such as speed optimization
> >> will bias towards saving/restoring more registers, and size optimization
> >> towards fewer.
> >>>>
> >>>> Likewise, only a relatively small number of functions actually hit the
> >>>> existing limits (likewise goes for functions which exceed 8 arguments;
> >>>> they exist, but the vast majority of function calls use fewer than 8
> >>>> arguments).
> >>>>
> >>>> ...

Re: Mixed EGU/EGO floating-point

<60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:4403:b0:6a0:5093:1742 with SMTP id v3-20020a05620a440300b006a050931742mr13270097qkp.691.1652725958050;
Mon, 16 May 2022 11:32:38 -0700 (PDT)
X-Received: by 2002:a54:4e92:0:b0:325:224c:8ff7 with SMTP id
c18-20020a544e92000000b00325224c8ff7mr8127103oiy.154.1652725957757; Mon, 16
May 2022 11:32:37 -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: Mon, 16 May 2022 11:32:37 -0700 (PDT)
In-Reply-To: <2022May16.114735@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:ed92:50fe:820d:b048;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:ed92:50fe:820d:b048
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 16 May 2022 18:32:38 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 3003
 by: MitchAlsup - Mon, 16 May 2022 18:32 UTC

On Monday, May 16, 2022 at 5:00:58 AM UTC-5, Anton Ertl wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
> >John Dallman <j...@cix.co.uk> schrieb:
> >> It is. A manufacturer once told us we could not expect bit-identical
> >> results between two different kinds of FP registers on the same machine,
> >> both usable at the same time. For ISVs who use compilers, rather than
> >> assembler, that's deadly.
> >
> >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) ?
<
> 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.
>
> 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.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Re: Mixed EGU/EGO floating-point

<7e44fd12-e4e2-48ca-ba41-45112e080d10n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:24cd:b0:6a0:414c:a648 with SMTP id m13-20020a05620a24cd00b006a0414ca648mr13634413qkn.465.1652731018069;
Mon, 16 May 2022 12:56:58 -0700 (PDT)
X-Received: by 2002:a05:6830:2467:b0:606:b036:b15f with SMTP id
x39-20020a056830246700b00606b036b15fmr6655692otr.213.1652731017848; Mon, 16
May 2022 12:56:57 -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: Mon, 16 May 2022 12:56:57 -0700 (PDT)
In-Reply-To: <60d76ecf-add0-44d2-8ef5-8b14184e48fan@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:2060:a91b:1a54:d855;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:2060:a91b:1a54:d855
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7e44fd12-e4e2-48ca-ba41-45112e080d10n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Mon, 16 May 2022 19:56:58 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1827
 by: Quadibloc - Mon, 16 May 2022 19:56 UTC

On Monday, May 16, 2022 at 12:32:39 PM UTC-6, MitchAlsup wrote:
> On Monday, May 16, 2022 at 5:00:58 AM UTC-5, Anton Ertl wrote:

> > One example that comes to my mind is IA-32/AMD64. They have the 387
> <
> Is it not x86-64 (AMD64) ?

Or, if you don't want to confuse people by expecting them to know the up-to-date
names for these things, but instead want to use the original names, perhaps something
like

EM64T/AMD64 (now known as x86-64)

would be clearest.

John Savard

Re: Mixed EGU/EGO floating-point

<t5ub0r$8cj$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!EhtdJS5E9ITDZpJm3Uerlg.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Mon, 16 May 2022 22:09:00 +0200
Organization: Aioe.org NNTP Server
Message-ID: <t5ub0r$8cj$1@gioia.aioe.org>
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> <hf9gK.27170$6dof.15166@fx13.iad>
<t5tps3$5u2$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="8595"; posting-host="EhtdJS5E9ITDZpJm3Uerlg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0 SeaMonkey/2.53.12
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Mon, 16 May 2022 20:09 UTC

Stephen Fuld wrote:
> On 5/15/2022 8:46 AM, EricP wrote:
>> Thomas Koenig wrote:
>>> Anton Ertl <anton@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.
>>>
>>> Simply ignoring values for summation would start leading to
>>> "interesting" results when you want to have an average instead of
>>> a sum, for example.
>>>
>>> Introducing new classes of numbers in floating point is no substitute
>>> for careful thought on part of the programmer.
>>
>> None/Null missing values occur all the time in datasets.
>> Applications that can have missing values already deal with this.
>> Currently they just all deal with it individually.
>>
>> It might be nice to standardize the behavior.
>>
>> For example, how should compare operators > >= < <=
>> work for different values of left and right operands,
>> so that it makes sense for Min(a,b) and Max(a,b).
>
> You might want to look at DB2 (IBM's relational database software).  It
> has supported missing values, called "Nulls", for decades, and it
> supports what are called aggregate functions such as sum, max, count,
> etc.  Note also that Nulls are supported for all types of data, not just
> floating point.  And no, I don't know what value(s) they use for null.  :-(

In one DB where I had to reverse engineeer the binary storage format,
all variables used a leading byte count, followed by a little-endian
array of bytes, just large enough to hold the actual value.

I.e. null as the leading byte always meant a DB Null, a zero
integer/decimal value was encoded as (1,0), i.e. a 1 count and a 0 value
byte.

In the DB tables I looked at there were no binary FP values and scaled
decimal was stored as integer with the fixed point scaling a part of the
table definition.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Re: Mixed EGU/EGO floating-point

<2022May16.222811@mips.complang.tuwien.ac.at>

 copy mid

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

 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: Mon, 16 May 2022 20:28:11 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 45
Message-ID: <2022May16.222811@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>
Injection-Info: reader02.eternal-september.org; posting-host="128a42e0247b02702bd84c94989e66d3";
logging-data="27927"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/CWdobNiwiXeecHTPyc3uX"
Cancel-Lock: sha1:Rn+AFg1smMzGS+6G87UIvNqidxo=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 16 May 2022 20:28 UTC

MitchAlsup <MitchAlsup@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.

>> 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.

-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

<t5udeo$uh9$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Mixed EGU/EGO floating-point
Date: Mon, 16 May 2022 13:50:32 -0700
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <t5udeo$uh9$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> <hf9gK.27170$6dof.15166@fx13.iad>
<t5tps3$5u2$1@dont-email.me> <t5ub0r$8cj$1@gioia.aioe.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 16 May 2022 20:50:32 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="9dceea0eea63448eb6fbeadc31a1ef7c";
logging-data="31273"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ioyDOvlh24i+dFtqoLdM/"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:BphLxA4ykRU55KE3uWD5AzMgNCE=
In-Reply-To: <t5ub0r$8cj$1@gioia.aioe.org>
Content-Language: en-US
 by: Ivan Godard - Mon, 16 May 2022 20:50 UTC

On 5/16/2022 1:09 PM, Terje Mathisen wrote:
> Stephen Fuld wrote:
>> On 5/15/2022 8:46 AM, EricP wrote:
>>> Thomas Koenig wrote:
>>>> Anton Ertl <anton@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.
>>>>
>>>> Simply ignoring values for summation would start leading to
>>>> "interesting" results when you want to have an average instead of
>>>> a sum, for example.
>>>>
>>>> Introducing new classes of numbers in floating point is no substitute
>>>> for careful thought on part of the programmer.
>>>
>>> None/Null missing values occur all the time in datasets.
>>> Applications that can have missing values already deal with this.
>>> Currently they just all deal with it individually.
>>>
>>> It might be nice to standardize the behavior.
>>>
>>> For example, how should compare operators > >= < <=
>>> work for different values of left and right operands,
>>> so that it makes sense for Min(a,b) and Max(a,b).
>>
>> You might want to look at DB2 (IBM's relational database software).
>> It has supported missing values, called "Nulls", for decades, and it
>> supports what are called aggregate functions such as sum, max, count,
>> etc.  Note also that Nulls are supported for all types of data, not
>> just floating point.  And no, I don't know what value(s) they use for
>> null.  :-(
>
> In one DB where I had to reverse engineeer the binary storage format,
> all variables used a leading byte count, followed by a little-endian
> array of bytes, just large enough to hold the actual value.
>
> I.e. null as the leading byte always meant a DB Null, a zero
> integer/decimal value was encoded as (1,0), i.e. a 1 count and a 0 value
> byte.
>
> In the DB tables I looked at there were no binary FP values and scaled
> decimal was stored as integer with the fixed point scaling a part of the
> table definition.

Sounds like a 1401.

Re: Mixed EGU/EGO floating-point

<7bdd45e4-6c72-40dd-b8a3-9c1914afa51cn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:2b09:b0:45b:59b:5df6 with SMTP id jx9-20020a0562142b0900b0045b059b5df6mr17016182qvb.22.1652736133709;
Mon, 16 May 2022 14:22:13 -0700 (PDT)
X-Received: by 2002:a05:6808:c2:b0:325:eb87:c26f with SMTP id
t2-20020a05680800c200b00325eb87c26fmr8948829oic.117.1652736133521; Mon, 16
May 2022 14:22:13 -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: Mon, 16 May 2022 14:22:13 -0700 (PDT)
In-Reply-To: <7e44fd12-e4e2-48ca-ba41-45112e080d10n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:ed92:50fe:820d:b048;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:ed92:50fe:820d:b048
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> <7e44fd12-e4e2-48ca-ba41-45112e080d10n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7bdd45e4-6c72-40dd-b8a3-9c1914afa51cn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 16 May 2022 21:22:13 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 2133
 by: MitchAlsup - Mon, 16 May 2022 21:22 UTC

On Monday, May 16, 2022 at 2:56:59 PM UTC-5, Quadibloc wrote:
> On Monday, May 16, 2022 at 12:32:39 PM UTC-6, MitchAlsup wrote:
> > On Monday, May 16, 2022 at 5:00:58 AM UTC-5, Anton Ertl wrote:
>
> > > One example that comes to my mind is IA-32/AMD64. They have the 387
> > <
> > Is it not x86-64 (AMD64) ?
> Or, if you don't want to confuse people by expecting them to know the up-to-date
> names for these things, but instead want to use the original names, perhaps something
> like
>
> EM64T/AMD64 (now known as x86-64)
<
It was known internally as x86-64 even before it became known of as x86-64 externally.
In fact, you use of AMD64 caught me completely by surprise !!
>
> would be clearest.
>
> John Savard

Re: Mixed EGU/EGO floating-point

<25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:4208:0:b0:461:d262:7842 with SMTP id k8-20020ad44208000000b00461d2627842mr4217198qvp.113.1652736351534;
Mon, 16 May 2022 14:25:51 -0700 (PDT)
X-Received: by 2002:aca:e155:0:b0:325:6d76:da4b with SMTP id
y82-20020acae155000000b003256d76da4bmr9259902oig.125.1652736351214; Mon, 16
May 2022 14:25:51 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.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: Mon, 16 May 2022 14:25:50 -0700 (PDT)
In-Reply-To: <2022May16.222811@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:ed92:50fe:820d:b048;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:ed92:50fe:820d:b048
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 16 May 2022 21:25:51 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Mon, 16 May 2022 21:25 UTC

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

Re: Mixed EGU/EGO floating-point

<cog58httrlpgbjsvq4bls55m8rp1eqb5ji@4ax.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.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: Mon, 16 May 2022 17:38:29 -0400
Organization: A noiseless patient Spider
Lines: 15
Message-ID: <cog58httrlpgbjsvq4bls55m8rp1eqb5ji@4ax.com>
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> <hf9gK.27170$6dof.15166@fx13.iad> <t5tps3$5u2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: reader02.eternal-september.org; posting-host="83c550a73d52b136c8622f38684d4fcc";
logging-data="19398"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+4OXfO/qbwu9yTUWkeojj0E5hoJobFx0w="
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha1:IbZNBVx5tjsmEMZDaZaNKme7I8E=
 by: George Neuner - Mon, 16 May 2022 21:38 UTC

On Mon, 16 May 2022 08:16:18 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>You might want to look at DB2 (IBM's relational database software). It
>has supported missing values, called "Nulls", for decades, and it
>supports what are called aggregate functions such as sum, max, count,
>etc. Note also that Nulls are supported for all types of data, not just
>floating point. And no, I don't know what value(s) they use for null. :-(

SQL DBMS typically will zero fields which are null - but the value
used is not relevant: each field in a record tuple has associated
metadata that indicates (among other things) whether its value is
valid.

George

Re: Mixed EGU/EGO floating-point

<2022May16.233218@mips.complang.tuwien.ac.at>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!rocksolid2!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: Mon, 16 May 2022 21:32:18 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 23
Message-ID: <2022May16.233218@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> <7e44fd12-e4e2-48ca-ba41-45112e080d10n@googlegroups.com>
Injection-Info: reader02.eternal-september.org; posting-host="128a42e0247b02702bd84c94989e66d3";
logging-data="9834"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Q9dzOZ0WecnyQ6Sx8u9gR"
Cancel-Lock: sha1:iOz/5wLqEZGfTdtJrgs/zHEVqoE=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 16 May 2022 21:32 UTC

Quadibloc <jsavard@ecn.ab.ca> writes:
>Or, if you don't want to confuse people by expecting them to know the up-to-date
>names for these things, but instead want to use the original names, perhaps something
>like
>
>EM64T/AMD64 (now known as x86-64)

First, AMD called it x86-64, later AMD64 (until now).

Later Intel called it IA32e, then EM64T, and now Intel 64.

Microsoft calls it x64.

I may have missed/forgotten some names. The Intel names are funny,
especially how they tried to de-emphasize this architecture in favour
of IA-64 for quite some time, but eventually swtched around, with this
architecture becoming "Intel 64" nd IA-64 being renamed into IPF or
somesuch.

- 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

<t5ui16$13m$1@dont-email.me>

 copy mid

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

 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: Mon, 16 May 2022 17:08:37 -0500
Organization: A noiseless patient Spider
Lines: 517
Message-ID: <t5ui16$13m$1@dont-email.me>
References: <t5qe8t$fh0$1@dont-email.me>
<memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de> <t5rn0u$lsi$1@dont-email.me>
<b78d6cfa-cba6-40ca-832b-86af306de767n@googlegroups.com>
<t5rum0$bu9$1@dont-email.me>
<2df555e6-2b58-4972-8fd2-87f8cace547dn@googlegroups.com>
<t5t2me$rh5$1@dont-email.me>
<36e5226f-2a99-45f4-aef8-4ef75b43ceecn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 16 May 2022 22:08:38 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="407bfcdffd720520a9d83d643dadfa29";
logging-data="1142"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Td1DWjysR85uDuvh7JFyX"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:cb0spffvOx4oAUSiMaf9i9wyYWU=
In-Reply-To: <36e5226f-2a99-45f4-aef8-4ef75b43ceecn@googlegroups.com>
Content-Language: en-US
 by: BGB - Mon, 16 May 2022 22:08 UTC

On 5/16/2022 1:30 PM, MitchAlsup wrote:
> On Monday, May 16, 2022 at 3:40:50 AM UTC-5, BGB wrote:
>> On 5/15/2022 6:15 PM, MitchAlsup wrote:
>>> On Sunday, May 15, 2022 at 5:26:11 PM UTC-5, BGB wrote:
>>
>>>> If XGPR is not enabled, we can assume that R32..R63 do not exist (and
>>>> the low bit of the register for 128-bit operations is "Must Be Zero").
>>> <
>>> What do you do for code compiled assuming XGPR exists and you want to
>>> run on THIS implementation ??
>> It wont work.
>>
>> These scenarios are not binary compatible with each other.
>>
> Code compiled for one member of My 66000 will run on all members of
> My 66000.

I was more following an approach more like that used by things like
MSP430 or Cortex-M or similar, where it is assumed that code is built
for a processor core with a matching feature-set.

One can then enable or disable features to get the core more-or-less
within the resource constraints.

Then I defined "profiles" which describe basic combinations of features
which are assumed to be "baseline" for that profile.

For example:
'A' profile: WEX, Jumbo, 128-bit SIMD, 48-bit virtual address space, ...
'G' profile: Like 'A', but adds 64 GPRs and a 96-bit address space
...

Then, 'E' and 'F', which have a much more limited feature-set, but are
small enough to fit on an XC7S25 or similar.

From what I gather, this isn't too different from what the RISC-V
people are doing in practice. Eg, code built for RV64GC isn't going to
run on an RV32I.

Granted, most of my active development recently has been on 'A' and 'G'
feature-set.

>>
>>
>> There is not strict requirement that code built for BJX2 with one
>> profile be able to run on a core built with a different profile.
>>
> I chose differently, so did Mill but they solved the problem differently.

Possibly.

My thinking was that for "portable code", it would likely be sent in an
IR form of some sort. Hadn't yet decided on anything specific yet though.

One option could be using my RIL format as a distribution format, but
RIL still can't completely abstract over some things. It also "isn't
great" in a few areas, and would require a somewhat more heavyweight
JIT/AOT than I would prefer.

I had a few times considered options for a 3AC IR, but not done much
development on this front yet. Nor fully resolved the issue of whether a
stack machine or 3AC IR would be "better" here (pros/cons either way).

I hadn't fully defined on a packaging format yet either, but a few of my
ideas would have essentially packaged the IR inside of RIFF or similar
(using a file structure loosely similar to the RIFF/AVI format).

Say, something like:
RIFF/RILB {
LIST/glbl {
... functions and globals ...
}
gidx {
... indices to globals ...
}
strs // string table
code // bytecode
}

With globals like:
gvar //global variable
gfcn //global function
...
Probably each holding a structure defining the various things.

Had designed a format sorta like this (would be used in place of the
existing RIL format, which also encodes metadata via the stack machine),
but it kinda stalled out at an early stage of development.

This would mostly change the packaging, but would leave the basic design
of the bytecode mostly intact.

MSIL / CIL would be another possibility, though the assumed runtime
requirements of .NET are a bit higher than I would prefer (and I am not
really all that inclined at present to write a .NET CLR implementation
for this).

Despite the hype, IMHO, WASM is "basically trash" on the IR design front.

Something "Sorta like LLVM bitcode, but with a format that is easy to
decode and not tied to LLVM" could also work. Though, still doesn't
address a few issues (bitcode still can't abstract over things like
"sizeof(void *)" or similar).

Seemingly, "Compile C into a portable IR which isn't trash" is a bit of
an unresolved issue.

One other big annoyance is that one of C's primary specialization
mechanisms, namely "#ifdef" applies very early in the compilation process.

BGBCC has an ifdef/ifarch mechanism, where certain #ifdef's can be
translated to: __ifdef(condition) { ... } or __ifarch(condition), which
can then be handled much later in the process (in the backend).

But, this approach only works in certain situations (can include/exclude
functions and other declarations, but do not for statement blocks or
syntactic elements).

They also don't currently work for things like typedefs.

At the ASM level, these are handled by .ifdef and .ifarch, where:
#ifdef FOO
... handled in frontend ...
#endif
.ifarch has_foo
... handled by assembler ...
.endif

This would be used for specializing for things like whether SIMD
instructions, XGPR, ... are enabled or disabled.

Though, I am not aware of other C compilers or IRs doing this.

This was a "future issue" though, as for the moment, program
distribution or binary compatibility between profiles isn't a huge issue.

>>
>> This is why there are "profiles".
>>
>> Code built for the baseline feature-set of one profile, will generally
>> be expected to run on cores for the same profile. However, code build
>> for the baseline of one profile will not necessarily be able to run on a
>> core implementing a different profile.
>>
>>
>> So, for example:
>> XGPR is an optional feature within the 'A' profile;
>> It is a baseline feature within the 'G' profile.
>>
>> Where:
>> G: Has 64 GPRs and a 96-bit address space.
>> A: Has WEX-3W, 32 GPRs, and a 48-bit address space.
>> C: Has WEX-3W, 32 GPRs, and a 32-bit address space (MMU).
>> F: Has FPU (scalar only) but no MMU.
>> E: No FPU or MMU.
>>
> My 66000 does not have E or F or C or A
> My 66000 only has 32×64-bit registers and 4×64-bit virtual and physical
> address spaces.

Fair enough, but I was not aware of a good cost-effective alternative.

The use-cases where 'E' or 'F' would be used typically don't have enough
RAM or ROM space to justify any sort of emulation layer.

Say, for example, if one has a memory map like:
00000000..0000BFFF: ROM (48K)
0000C000..0000FFFF: RAM (16K)
F0000000..FFFFFFFF: MMIO

Doesn't make sense to worry about trying to emulate a bigger profile.

On the lower end, this is what I am dealing with (mostly because boards
like the CMod-S7 lack an external RAM chip, and there isn't really a
huge amount of Block-RAM in an XC7S25 or similar).

If there is additional RAM, it can be put in the usual range, say, for a
CMod-A7, one could potentially do:
00000000..0000BFFF: ROM (48K)
0000C000..0000BFFF: RAM (8K)
01000000..0107FFFF: RAM (512K QSPI SRAM)
F0000000..FFFFFFFF: MMIO

....

>>
>> 'G' profile code will not run on an A profile core, and 'A' profile code
>> will not run on 'F'
>>
>> The G profile will need something like an XC7A100T, whereas the E
>> profile can fit on an XC7S25.
>>
>>
>> However... Despite being the same ISA, they are different enough as to
>> not be binary compatible with each other.
>>
>> 'E' and 'F' profiles being basically scalar RISC machines.
>>
> You get to make this poor choice.

This sorta thing seemed to work fine for Texas Instruments and similar...

>>
> ------------------------
>>> The compiler can save as many or as few registers between R16 and R29
>>> as it desired, can save an update FP as desired, can save and restore SP
>>> if desired (seldom) or just update and backdate SP as desired. If desired
>>> Registers R1-R8 (arguments) can be saved--and here they get concatenated
>>> with the stack passed arguments for ease of varargs.
>>> <
>>> So, the compiler gets to choose how many and if.
>> The compiler chooses in this case as well, but the compiler is limited
>> in terms of its own cleverness...
>>
>> One can more easily do "perfect fit" when writing ASM.
>>
> What ?

In ASM, one can choose exactly how many registers to save and restore,
one has free choice which registers are used and where, ...

>>>>
>>>> If I enabled R32..R63 in the main C ABI:
>>>> R40..R47: Enabled for very high register pressure.
>>>> R56..R63: Enabled for very high register pressure.
>>>> R32..R39: Enabled for very high pressure leaf functions.
>>>> R48..R55: Enabled for very high pressure leaf functions.
>>>>
>>> <
>>> With only 32 registers (1 being SP and 1 optionally being FP) I am finding
>>> very little spill/fill codes, so whatever LLVM did and whatever Brian's
>>> My 66000 port does, I don't seem to run into the mentioned problems.
> <
>> I have 32 registers, but still see a lot of spill/fill.
>>
>> A fair chunk of this though is because my compiler isn't smart enough to
>> keep values in registers across basic blocks without statically
>> assigning them to a register for the functions entire lifespan.
>>
>> It also "wastes" a lot of registers on things like temporaries (with
>> associated RegReg MOV instructions).
> <
> My 66000 wastes 0 registers on constants, immediates, and displacements
> {except when passing an immediate to a subroutine or initializing a register
> to a constant value.}
> <


Click here to read the complete article
Re: Mixed EGU/EGO floating-point

<694aa4d9-ac73-4d35-9bf0-23813b6d3fa6n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1195:b0:2f3:b8bf:46ab with SMTP id m21-20020a05622a119500b002f3b8bf46abmr17411007qtk.190.1652741764319;
Mon, 16 May 2022 15:56:04 -0700 (PDT)
X-Received: by 2002:a05:6870:7084:b0:ed:d709:34be with SMTP id
v4-20020a056870708400b000edd70934bemr15849758oae.4.1652741764122; Mon, 16 May
2022 15:56:04 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.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: Mon, 16 May 2022 15:56:03 -0700 (PDT)
In-Reply-To: <t5ui16$13m$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:ed92:50fe:820d:b048;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:ed92:50fe:820d:b048
References: <t5qe8t$fh0$1@dont-email.me> <memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de> <t5rn0u$lsi$1@dont-email.me>
<b78d6cfa-cba6-40ca-832b-86af306de767n@googlegroups.com> <t5rum0$bu9$1@dont-email.me>
<2df555e6-2b58-4972-8fd2-87f8cace547dn@googlegroups.com> <t5t2me$rh5$1@dont-email.me>
<36e5226f-2a99-45f4-aef8-4ef75b43ceecn@googlegroups.com> <t5ui16$13m$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <694aa4d9-ac73-4d35-9bf0-23813b6d3fa6n@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 16 May 2022 22:56:04 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Mon, 16 May 2022 22:56 UTC

On Monday, May 16, 2022 at 5:08:41 PM UTC-5, BGB wrote:
> On 5/16/2022 1:30 PM, MitchAlsup wrote:
> > On Monday, May 16, 2022 at 3:40:50 AM UTC-5, BGB wrote:

>
>
>
> The use-cases where 'E' or 'F' would be used typically don't have enough
> RAM or ROM space to justify any sort of emulation layer.
>
> Say, for example, if one has a memory map like:
> 00000000..0000BFFF: ROM (48K)
> 0000C000..0000FFFF: RAM (16K)
> F0000000..FFFFFFFF: MMIO
>
> Doesn't make sense to worry about trying to emulate a bigger profile.
>
I just don't want to invest anything more in a 32-bit world. As long as the
64-bit world has simple processors where one can fit 100 of them on
a 7nm die. Each processor in real silicon is now so tiny they put dozens
of great big complicated cores on a single die. A single 64-bit processor
is almost too small to conceive of by itself on a single die.
.......................
> >>
> >> One can more easily do "perfect fit" when writing ASM.
> >>
> > What ?
> In ASM, one can choose exactly how many registers to save and restore,
> one has free choice which registers are used and where, ...
<
The compiler has a free choice of how many registers to save in ENTER
and EXIT.
<
> >>>>
> >>>> If I enabled R32..R63 in the main C ABI:
> >>>> R40..R47: Enabled for very high register pressure.
> >>>> R56..R63: Enabled for very high register pressure.
> >>>> R32..R39: Enabled for very high pressure leaf functions.
> >>>> R48..R55: Enabled for very high pressure leaf functions.
> >>>>
> >>> <
> >>> With only 32 registers (1 being SP and 1 optionally being FP) I am finding
> >>> very little spill/fill codes, so whatever LLVM did and whatever Brian's
> >>> My 66000 port does, I don't seem to run into the mentioned problems.
> > <
> >> I have 32 registers, but still see a lot of spill/fill.
> >>
> >> A fair chunk of this though is because my compiler isn't smart enough to
> >> keep values in registers across basic blocks without statically
> >> assigning them to a register for the functions entire lifespan.
> >>
> >> It also "wastes" a lot of registers on things like temporaries (with
> >> associated RegReg MOV instructions).
> > <
> > My 66000 wastes 0 registers on constants, immediates, and displacements
> > {except when passing an immediate to a subroutine or initializing a register
> > to a constant value.}
> > <
> Most large immediate values can be encoded in BJX2 as well via Jumbo
> encodings.
<
most versus all--this eliminates a strategy from the compiler for dealing with
constants that don't fit a particular encoding.
>
> This doesn't eliminate the use of temporary values or unnecessary
> register-moves by the compiler though.
>
I don't see unnecessary things like that--just more opportunities for the compiler
>
> Some amount are a result of implicit type conversions or promotions:
>
> Consider, for example, in C one writes:
> short x;
> int y;
> ...
> y=x;
>
> Then the front-end is like "Are 'short' and 'int' compatible? No", so
> emits it as (3AC IR notation):
> CONV ty=00 sty=0A dst=T2.1 srca=L0.1
> MOV ty=00 dst=L2.1 srca=T2.1
>
> Then it reaches the back-end, and gets turned into, say:
> EXTS.W R8, R4
> MOV R4, R9
<
Yech:: why not go directly to EXTS.W R8,R9
or peep hole it.
>
> When in all likelihood the compiler could have just done:
> MOV R8, R9
<
In K&R days this would have been legal. It is doubtful that it remains legal
in a software environment with multiple language front ends feeding a
common code generator for a host of languages that can share "shared
libraries". ADA calls C calls FORTRAN calls ADA,...
<
Not allowing register containers to contain values the corresponding
memory container could contain suppresses overflow/underflow/wrapping
bugs.
<
With that said:: LDs of small container get expanded to fir register sized containers
upon delivery of the memory value. So, the majority of these conversions are
avoided.
<
> Or, maybe even, have just redirected references to 'y' to have used the
> value from 'x' without having needed to move it.
>
>
> There is some amount of logic to try to limit how many extra temporaries
> are created, and this part of the process is also heavily tied in with
> the behavior of the RPN / Stack-Machine stage (used by RIL).
<snip>
>
> It is a similar problem with trying to prune temporaries being spilled
> to the stack. Most of the time this is unnecessary, but every so often,
> a temporary is used as an input to another basic block, and so as a
> result it is necessary to keep on spilling the temporaries to the stack
> (*1).
>
Temporaries have context, and if the expression being compiled gets
bigger than the effective size of the register file, then spill/fill code
is created. I just happen to see very little of this spill/fill code. I suspect
the compiler chooses to evaluate the calculation in a way that minimizes
the number of registers required.
<snip>
> > LLVM intermediate has all the clues to sorting this out.
> Yeah.
>
> LLVM IR is in some ways "less terrible" than what I am doing in BGBCC,
> though trying to imitate LLVM in these areas is "easier said than done".
>
>
> Though for all its faults, BGBCC rebuilds from source in a few seconds,
> which is more than I can say of LLVM.

Re: Mixed EGU/EGO floating-point

<52de9023-d33c-4a1e-bb67-50928f1274afn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1007:b0:2f3:ce52:25cb with SMTP id d7-20020a05622a100700b002f3ce5225cbmr17103050qte.575.1652743055782;
Mon, 16 May 2022 16:17:35 -0700 (PDT)
X-Received: by 2002:a05:6870:80ca:b0:f1:8fad:d9d1 with SMTP id
r10-20020a05687080ca00b000f18fadd9d1mr5609086oab.125.1652743055596; Mon, 16
May 2022 16:17:35 -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: Mon, 16 May 2022 16:17:35 -0700 (PDT)
In-Reply-To: <2022May16.233218@mips.complang.tuwien.ac.at>
Injection-Info: google-groups.googlegroups.com; posting-host=2001:56a:fb70:6300:bced:802d:193f:4347;
posting-account=1nOeKQkAAABD2jxp4Pzmx9Hx5g9miO8y
NNTP-Posting-Host: 2001:56a:fb70:6300:bced:802d:193f:4347
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> <7e44fd12-e4e2-48ca-ba41-45112e080d10n@googlegroups.com>
<2022May16.233218@mips.complang.tuwien.ac.at>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <52de9023-d33c-4a1e-bb67-50928f1274afn@googlegroups.com>
Subject: Re: Mixed EGU/EGO floating-point
From: jsav...@ecn.ab.ca (Quadibloc)
Injection-Date: Mon, 16 May 2022 23:17:35 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1872
 by: Quadibloc - Mon, 16 May 2022 23:17 UTC

On Monday, May 16, 2022 at 3:41:56 PM UTC-6, Anton Ertl wrote:
> The Intel names are funny,
> especially how they tried to de-emphasize this architecture in favour
> of IA-64 for quite some time,

IA-64, of course, for the benefit of those not familiar with these
abbreviations, being the infamous Itanium.

Oh, dear, that's alliterative. Perhaps it should be tied up with the
crimson bands of Cytorrak for safekeeping.

John Savard

Re: Mixed EGU/EGO floating-point

<t5v0pv$jtj$1@dont-email.me>

 copy mid

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

 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: Mon, 16 May 2022 21:20:45 -0500
Organization: A noiseless patient Spider
Lines: 356
Message-ID: <t5v0pv$jtj$1@dont-email.me>
References: <t5qe8t$fh0$1@dont-email.me>
<memo.20220515153920.11824J@jgd.cix.co.uk>
<t5rco4$ga5$1@newsreader4.netcologne.de> <t5rn0u$lsi$1@dont-email.me>
<b78d6cfa-cba6-40ca-832b-86af306de767n@googlegroups.com>
<t5rum0$bu9$1@dont-email.me>
<2df555e6-2b58-4972-8fd2-87f8cace547dn@googlegroups.com>
<t5t2me$rh5$1@dont-email.me>
<36e5226f-2a99-45f4-aef8-4ef75b43ceecn@googlegroups.com>
<t5ui16$13m$1@dont-email.me>
<694aa4d9-ac73-4d35-9bf0-23813b6d3fa6n@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 02:20:47 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="407bfcdffd720520a9d83d643dadfa29";
logging-data="20403"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+p9wYRsNekZ2ln0pEaFdN"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:jkzo//24lLFre7vIk5unaSe9rgg=
In-Reply-To: <694aa4d9-ac73-4d35-9bf0-23813b6d3fa6n@googlegroups.com>
Content-Language: en-US
 by: BGB - Tue, 17 May 2022 02:20 UTC

On 5/16/2022 5:56 PM, MitchAlsup wrote:
> On Monday, May 16, 2022 at 5:08:41 PM UTC-5, BGB wrote:
>> On 5/16/2022 1:30 PM, MitchAlsup wrote:
>>> On Monday, May 16, 2022 at 3:40:50 AM UTC-5, BGB wrote:
>
>>
>>
>>
>> The use-cases where 'E' or 'F' would be used typically don't have enough
>> RAM or ROM space to justify any sort of emulation layer.
>>
>> Say, for example, if one has a memory map like:
>> 00000000..0000BFFF: ROM (48K)
>> 0000C000..0000FFFF: RAM (16K)
>> F0000000..FFFFFFFF: MMIO
>>
>> Doesn't make sense to worry about trying to emulate a bigger profile.
>>
> I just don't want to invest anything more in a 32-bit world. As long as the
> 64-bit world has simple processors where one can fit 100 of them on
> a 7nm die. Each processor in real silicon is now so tiny they put dozens
> of great big complicated cores on a single die. A single 64-bit processor
> is almost too small to conceive of by itself on a single die.
> ......................

The ISA is still 64-bit in these profiles, just using a 32-bit
physically-mapped address space. With bits (63:32) being ignored for
memory accesses and similar.

Generally, there is very little RAM or ROM because:
The relevant FPGA boards lack much (or any) external RAM;
FPGA BlockRAM is fairly limited on the XC7S25.

One could also argue for:
RV32I or RV32E (32-bit RISC-V)
Arguably a better fit from a technical POV
B32V (SuperH based)
Mostly resembled a SH-2 / SH-4 hybrid.
BSR1
This was the direct basis of BJX2's ISA encoding.
Was intended to be simplified relative to SuperH.
ISA was also designed to try to mimic the MSP430.

I ended up using BJX2 here because:
Less fragmentation in terms of my efforts
I could still fit it into an XC7S25
Differences in LUT cost weren't all that significant.

In these cases, it isn't intended to be used as a general purpose ISA,
but more as a microcontroller.

Vs an MSP430:
Significantly higher performance;
Can do fast / customizable IO;
...
However:
Per-unit, the CMod S7 is around 20-30 times the cost of an MSP430Gxxx;
Cost is a lot closer if compared with a RasPi;
RasPi having much faster CPU, but much more limited GPIO;
RasPi Pico could be a good option here:
More cost-competitive with the MSP430;
More RAM and cheaper than a CMod S7.

>>>>
>>>> One can more easily do "perfect fit" when writing ASM.
>>>>
>>> What ?
>> In ASM, one can choose exactly how many registers to save and restore,
>> one has free choice which registers are used and where, ...
> <
> The compiler has a free choice of how many registers to save in ENTER
> and EXIT.
> <

Yeah.

Choice in my case is free, because it is ultimately just Load/Store
instructions...

But, just because it is a free choice, doesn't mean my compiler isn't
going to be stupid about it.

Which is partly why the compiler uses heuristics to enable or disable
parts of the register space for the register allocator.

Frequently, the register allocator will end up trying to allocate all
the registers within the space it has access to, but sometimes it is
faster to artificially limit this.

So, one might use an early pass to try to generate an estimate of the
total register pressure for the function, to then figure out how many
registers to allow it to use (with slightly different tuning parameters
for speed and size optimization)

>>>>>>
>>>>>> If I enabled R32..R63 in the main C ABI:
>>>>>> R40..R47: Enabled for very high register pressure.
>>>>>> R56..R63: Enabled for very high register pressure.
>>>>>> R32..R39: Enabled for very high pressure leaf functions.
>>>>>> R48..R55: Enabled for very high pressure leaf functions.
>>>>>>
>>>>> <
>>>>> With only 32 registers (1 being SP and 1 optionally being FP) I am finding
>>>>> very little spill/fill codes, so whatever LLVM did and whatever Brian's
>>>>> My 66000 port does, I don't seem to run into the mentioned problems.
>>> <
>>>> I have 32 registers, but still see a lot of spill/fill.
>>>>
>>>> A fair chunk of this though is because my compiler isn't smart enough to
>>>> keep values in registers across basic blocks without statically
>>>> assigning them to a register for the functions entire lifespan.
>>>>
>>>> It also "wastes" a lot of registers on things like temporaries (with
>>>> associated RegReg MOV instructions).
>>> <
>>> My 66000 wastes 0 registers on constants, immediates, and displacements
>>> {except when passing an immediate to a subroutine or initializing a register
>>> to a constant value.}
>>> <
>> Most large immediate values can be encoded in BJX2 as well via Jumbo
>> encodings.
> <
> most versus all--this eliminates a strategy from the compiler for dealing with
> constants that don't fit a particular encoding.

It depends some:
MOV Imm64, Rn //R0..R63 can be encoded
ADD Imm64, Rn //R0..R63 can be encoded

But:
OP Imm33s, Rn //R0..R31 only
OP Rm, Imm33s, Rn //R0..R31 only
LD (Rm, Disp33s), Rn //R0..R31 only
ST Rn, (Rm, Disp33s) //R0..R31 only
If you want R32..R63, then the Imm/Disp field drops to Imm17s/Disp17s.

There are (theoretical) encodings for Imm56s forms:
OP Rm, Imm56s, Rn
But, these are not currently used "in the real world".

It is also theoretically possible one could use a Jumbo prefix with an
XGPR Encoding:
FEii-iiii-9wnm-Zeii

This would allow the above cases, but IIRC these encodings are not
currently supported.

However... This only applies to instructions which exist in forms which
have an Imm9/Imm10/Disp10 form.

If all that exists in the base ISA is a "OP Rs, Rt, Rn" encoding,
typically, no immediate form exists.

In other cases, it will be necessary to load a constant into a register.

So, what instructions have Imm9 forms:
ADD (SUB)
ADDS.L/ADDU.L (SUBS.L/SUBU.L)
MULS.L, MULU.L
AND, OR, XOR

And, various 2RI forms:
TESTQ Imm, Rn
CMPEQ Imm, Rn
CMPQEQ Imm, Rn
CMPGT Imm, Rn
CMPQGT Imm, Rn
...

In some other cases, no immediate-form of the instruction exists, so the
assembler will "fake it" by doing a constant load into R0 and then using
R0 as an operand.

>>
>> This doesn't eliminate the use of temporary values or unnecessary
>> register-moves by the compiler though.
>>
> I don't see unnecessary things like that--just more opportunities for the compiler
>>
>> Some amount are a result of implicit type conversions or promotions:
>>
>> Consider, for example, in C one writes:
>> short x;
>> int y;
>> ...
>> y=x;
>>
>> Then the front-end is like "Are 'short' and 'int' compatible? No", so
>> emits it as (3AC IR notation):
>> CONV ty=00 sty=0A dst=T2.1 srca=L0.1
>> MOV ty=00 dst=L2.1 srca=T2.1
>>
>> Then it reaches the back-end, and gets turned into, say:
>> EXTS.W R8, R4
>> MOV R4, R9
> <
> Yech:: why not go directly to EXTS.W R8,R9
> or peep hole it.

Every special case adds hair, and potential for bugs, there are a lot of
special cases already.

The RPN -> 3AC stage is already kind of a tangled mess with
pattern-matching special cases.

As noted, a partial workaround is fusing the destination into the
operator. This is only done in certain cases though. Many operators will
simply push their result to the stack via a temporary rather than
directly target a destination variable (where pretty much any
intermediate value that is pushed to the stack, does so via a temporary;
but then the 3AC stage has no way to know it is too late).

But, by the time we reach the 3AC, it is already too late:
To eliminate the temporary, one has to prove that the temporary can't
(potentially) be accessed from some other control flow path.

Similarly, once one is in the backend, there is no good way to know this.

But, there isn't really much "viable" solution other than "exhaustively"
putting special cases in every possible place these situations can come
up in the RPN->3AC translation stage.

Pretty much, this was what a "phi operator" would be intended to
address, since if one had a phi operator one could track (as a graph)
all the locations that a given variable could "flow into", and this more
easily prove that its value wasn't used somewhere else.


Click here to read the complete article
Re: Mixed EGU/EGO floating-point

<t5v565$9s4$1@dont-email.me>

 copy mid

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

 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: Mon, 16 May 2022 22:35:31 -0500
Organization: A noiseless patient Spider
Lines: 122
Message-ID: <t5v565$9s4$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 17 May 2022 03:35:33 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="407bfcdffd720520a9d83d643dadfa29";
logging-data="10116"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18HCccbe6qsaYH73cJMi7Wu"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:vtAIk+QzF2N6F7ir5gZ3C9WNXE8=
In-Reply-To: <25188df4-4814-4348-bb35-29d32ae8b61dn@googlegroups.com>
Content-Language: en-US
 by: BGB - Tue, 17 May 2022 03:35 UTC

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...

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.

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

Re: Mixed EGU/EGO floating-point

<t5vg7m$3is$1@dont-email.me>

 copy mid

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

 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 01:44:05 -0500
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <t5vg7m$3is$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>
<2022May16.080036@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 17 May 2022 06:44:07 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="407bfcdffd720520a9d83d643dadfa29";
logging-data="3676"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+itfma+up+QRuUtcrfLHRH"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:5JKbHMMzvAwLgcDSZY0SztGLhGE=
In-Reply-To: <2022May16.080036@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: BGB - Tue, 17 May 2022 06:44 UTC

On 5/16/2022 1:00 AM, Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>> Anton Ertl <anton@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

But, dunno...

> - anton

Re: Mixed EGU/EGO floating-point

<t5vi1s$er3$1@dont-email.me>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!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 02:15:07 -0500
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <t5vi1s$er3$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 17 May 2022 07:15:09 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="407bfcdffd720520a9d83d643dadfa29";
logging-data="15203"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+gI4jg6hLMQXmyjtLuoklM"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:72TJKh69QBg7e/eWzj69rn4dBoA=
In-Reply-To: <337779ea-5572-4cf6-a663-d0ab990ecbbdn@googlegroups.com>
Content-Language: en-US
 by: BGB - Tue, 17 May 2022 07:15 UTC

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

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

<t5vipu$je7$1@dont-email.me>

 copy mid

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

 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 02:27:57 -0500
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <t5vipu$je7$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> <hf9gK.27170$6dof.15166@fx13.iad>
<t5r9vs$f19$1@newsreader4.netcologne.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 17 May 2022 07:27:58 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="407bfcdffd720520a9d83d643dadfa29";
logging-data="19911"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18QE/qwfnI4uKwQKWHEvIW+"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.9.0
Cancel-Lock: sha1:KNe+10qGNAubAs5rasgK4MFry/U=
In-Reply-To: <t5r9vs$f19$1@newsreader4.netcologne.de>
Content-Language: en-US
 by: BGB - Tue, 17 May 2022 07:27 UTC

On 5/15/2022 11:33 AM, Thomas Koenig wrote:
> EricP <ThatWouldBeTelling@thevillage.com> schrieb:
>> Thomas Koenig wrote:
>>> Anton Ertl <anton@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.
>>>
>>> Simply ignoring values for summation would start leading to
>>> "interesting" results when you want to have an average instead of
>>> a sum, for example.
>>>
>>> Introducing new classes of numbers in floating point is no substitute
>>> for careful thought on part of the programmer.
>>
>> None/Null missing values occur all the time in datasets.
>> Applications that can have missing values already deal with this.
>> Currently they just all deal with it individually.
>>
>> It might be nice to standardize the behavior.
>
> This so strongly depends on the application that any attempt to
> standardize via a new numeric type is likely to fail in the huge
> majority of cases.

Agreed.

Could they be useful? Maybe.

Do they make sense to add to FPU semantics? Doubtful.

Could make sense to add it via adding something like a NaN box type-tag
checking instruction, which could also be potentially used to aide code
which makes heavy use of NaN boxing (well, assuming such code would
actually use it, vs just bit-twiddling stuff in C, which is a bit of a
stretch).

....

Re: Mixed EGU/EGO floating-point

<t60ab0$fb6$2@newsreader4.netcologne.de>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!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:09:36 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t60ab0$fb6$2@newsreader4.netcologne.de>
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>
Injection-Date: Tue, 17 May 2022 14:09:36 -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:09 UTC

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>Anton Ertl <anton@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.

Pages:12345
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor