Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

A pain in the ass of major dimensions. -- C. A. Desoer, on the solution of non-linear circuits


devel / comp.arch / Re: VVM question

SubjectAuthor
* VVM questionThomas Koenig
+* Re: VVM questionAnton Ertl
|+* Re: VVM questionThomas Koenig
||`* Re: VVM questionAnton Ertl
|| `- Re: VVM questionThomas Koenig
|`* Re: VVM questionThomas Koenig
| +* Re: VVM questionAnton Ertl
| |`* Re: VVM questionThomas Koenig
| | `- Re: VVM questionAnton Ertl
| `* Re: VVM questionQuadibloc
|  `- Re: VVM questionAnton Ertl
+* Re: VVM questionTerje Mathisen
|`- Re: VVM questionThomas Koenig
`* Re: VVM questionMitchAlsup
 `* Re: VVM questionThomas Koenig
  +* Re: VVM questionStephen Fuld
  |`* Re: VVM questionAnton Ertl
  | `* Re: VVM questionTerje Mathisen
  |  +- Re: VVM questionluke.l...@gmail.com
  |  `* Re: VVM questionluke.l...@gmail.com
  |   +* Re: VVM questionTerje Mathisen
  |   |`- Re: VVM questionluke.l...@gmail.com
  |   `* Re: VVM questionMitchAlsup
  |    `- Re: VVM questionluke.l...@gmail.com
  +* Re: VVM questionMitchAlsup
  |`* Re: VVM questionStephen Fuld
  | `* Re: VVM questionThomas Koenig
  |  `* Re: VVM questionStephen Fuld
  |   `* Re: VVM questionMitchAlsup
  |    `* Re: VVM questionThomas Koenig
  |     +* Re: VVM questionMitchAlsup
  |     |+* Re: VVM questionluke.l...@gmail.com
  |     ||`* Re: VVM questionMitchAlsup
  |     || +- Re: VVM questionluke.l...@gmail.com
  |     || +* Re: VVM questionEricP
  |     || |+- Re: VVM questionluke.l...@gmail.com
  |     || |`- Re: VVM questionMitchAlsup
  |     || `* Re: VVM questionTerje Mathisen
  |     ||  +* Re: VVM questionEricP
  |     ||  |`* Re: VVM questionMitchAlsup
  |     ||  | `* Re: VVM questionThomas Koenig
  |     ||  |  +* Re: VVM questionMitchAlsup
  |     ||  |  |`- Re: VVM questionThomas Koenig
  |     ||  |  `* Re: VVM questionAnton Ertl
  |     ||  |   `* Re: VVM questionIvan Godard
  |     ||  |    `- Re: VVM questionTerje Mathisen
  |     ||  +* Re: VVM questionluke.l...@gmail.com
  |     ||  |`- Re: VVM questionMitchAlsup
  |     ||  `* Re: VVM questionStephen Fuld
  |     ||   `* Re: VVM questionluke.l...@gmail.com
  |     ||    `* Re: VVM questionMitchAlsup
  |     ||     +* Re: VVM questionluke.l...@gmail.com
  |     ||     |+- Re: VVM questionMitchAlsup
  |     ||     |`* Re: VVM questionIvan Godard
  |     ||     | `* Re: VVM questionMitchAlsup
  |     ||     |  `* Re: VVM questionIvan Godard
  |     ||     |   `* Re: VVM questionMitchAlsup
  |     ||     |    `- Re: VVM questionIvan Godard
  |     ||     `* Re: VVM questionStephen Fuld
  |     ||      `- Re: VVM questionMitchAlsup
  |     |`- Re: VVM questionluke.l...@gmail.com
  |     `* Re: VVM questionStephen Fuld
  |      +* Re: VVM questionThomas Koenig
  |      |+* Re: VVM questionTerje Mathisen
  |      ||+* Re: VVM questionThomas Koenig
  |      |||`* Re: VVM questionMitchAlsup
  |      ||| +- Re: VVM questionThomas Koenig
  |      ||| `* Re: VVM questionThomas Koenig
  |      |||  `- Re: VVM questionMitchAlsup
  |      ||`- Re: VVM questionMitchAlsup
  |      |+- Re: VVM questionStephen Fuld
  |      |`- Re: VVM questionMitchAlsup
  |      `* Re: VVM questionMitchAlsup
  |       +* Re: VVM questionStephen Fuld
  |       |`* Re: VVM questionMitchAlsup
  |       | +- Re: VVM questionTerje Mathisen
  |       | `* Re: VVM questionStephen Fuld
  |       |  `- Re: VVM questionluke.l...@gmail.com
  |       `* Re: VVM questionThomas Koenig
  |        `- Re: VVM questionMitchAlsup
  `* Re: VVM questionluke.l...@gmail.com
   `- Re: VVM questionMitchAlsup

Pages:1234
Re: VVM question

<6528a872-fbf0-436c-900e-b3a4740e984en@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:6b8b:: with SMTP id z11mr13530717qts.153.1630172799652; Sat, 28 Aug 2021 10:46:39 -0700 (PDT)
X-Received: by 2002:a9d:7204:: with SMTP id u4mr13606659otj.276.1630172799436; Sat, 28 Aug 2021 10:46:39 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!4.us.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 28 Aug 2021 10:46:39 -0700 (PDT)
In-Reply-To: <4ArWI.8247$o45.3531@fx46.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com> <sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com> <sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de> <sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com> <sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com> <b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com> <4ArWI.8247$o45.3531@fx46.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <6528a872-fbf0-436c-900e-b3a4740e984en@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sat, 28 Aug 2021 17:46:39 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 36
 by: MitchAlsup - Sat, 28 Aug 2021 17:46 UTC

On Saturday, August 28, 2021 at 9:17:41 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Friday, August 27, 2021 at 5:05:20 PM UTC-5, luke.l...@gmail.com wrote:
> >> On Monday, August 23, 2021 at 10:55:26 PM UTC+1, MitchAlsup wrote:
> >>
> >>> The major problem is where does one store the state on an interrupt
> >>> taken inside of the loop. I am letting my subconscious dwell on it right
> >>> now.
> > <
> > Reminding others that this state is 1076 bits long.
> > <
> >> the answer is, without an actual register, you can't.
> >>
> >> even if it was a Special Purpose register for storing
> >> in-flight data, it's still a register.
> >>
> >> if it was an actual GPR/FPR, actually named
> >> in the instruction (and given as a src/dst into
> >> the FMAC as the accumulator) *now* you
> >> have a register to actually store in-flight
> >> data during an interrupt. it can even be
> >> context switched.
> > <
> > OK, so what register do you have that is big enough to hold all 1076 bits ?
> >> a lot of things in SVP64 look overly complex until precise interrupt
> >> handling is thrown into the pot.
> >>
> >> l.
> Did you decide against the barf-buffer?
<
No, I was simply reinforcing the notion that IEEE 754 requires an infinitely
precise result prior to rounding. And in the case of reductions, 1076-bits
is enough, while 64 and 128 definitely are not.
<
Any advancement of 754 needs to remain aware of the progress of unums
in order to stay the preferred FP standard. Unums have the quire, 754 needs
something at least as good.

Re: VVM question

<sggpif$1pld$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!ppYixYMWAWh/woI8emJOIQ.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: VVM question
Date: Sun, 29 Aug 2021 22:09:50 +0200
Organization: Aioe.org NNTP Server
Message-ID: <sggpif$1pld$1@gioia.aioe.org>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de>
<3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Info: gioia.aioe.org; logging-data="59053"; posting-host="ppYixYMWAWh/woI8emJOIQ.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.8.1
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Sun, 29 Aug 2021 20:09 UTC

MitchAlsup wrote:
> On Friday, August 27, 2021 at 5:05:20 PM UTC-5, luke.l...@gmail.com wrote:
>> On Monday, August 23, 2021 at 10:55:26 PM UTC+1, MitchAlsup wrote:
>>
>>> The major problem is where does one store the state on an interrupt
>>> taken inside of the loop. I am letting my subconscious dwell on it right
>>> now.
> <
> Reminding others that this state is 1076 bits long.

I would in fact (strongly) prefer for this super accumulator to have
quite a few guard bits! I.e. if I add & subtract a bunch of values then
depending upon the order I might have a temporary overflow which
wouldn't have happened with some other reduction order.

How many would be enough?

For sum reductions 32 extra bits would allow arbitrary ordering of at
least a few billion items, so that's plenty. The additional cost of
going to 1108 instead of 1076 bits seems miniscule.
:-)

We still need some (really fast!) storage if this resource needs to be
interruptable, otherwise we would be left with a (memory-mapped?)
accelerator which you would ask the OS to allocate to you for the
duration, but with the additional cost that you would need to write all
the results to this unit. That could still be OK if it is on-chip and
can accept several store operations/cycle.

Doing it this way removes the interruptability requirement, at the cost
of needing a driver to handle arbitration.

Terje

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

Re: VVM question

<K3SWI.442$7U3.268@fx24.iad>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.swapon.de!news.uzoreto.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!peer01.ams4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx24.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: VVM question
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com> <sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com> <sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de> <sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com> <sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com> <b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com> <sggpif$1pld$1@gioia.aioe.org>
In-Reply-To: <sggpif$1pld$1@gioia.aioe.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 47
Message-ID: <K3SWI.442$7U3.268@fx24.iad>
X-Complaints-To: abuse@UsenetServer.com
NNTP-Posting-Date: Sun, 29 Aug 2021 20:26:18 UTC
Date: Sun, 29 Aug 2021 16:26:06 -0400
X-Received-Bytes: 3086
 by: EricP - Sun, 29 Aug 2021 20:26 UTC

Terje Mathisen wrote:
> MitchAlsup wrote:
>> On Friday, August 27, 2021 at 5:05:20 PM UTC-5, luke.l...@gmail.com
>> wrote:
>>> On Monday, August 23, 2021 at 10:55:26 PM UTC+1, MitchAlsup wrote:
>>>
>>>> The major problem is where does one store the state on an interrupt
>>>> taken inside of the loop. I am letting my subconscious dwell on it
>>>> right
>>>> now.
>> <
>> Reminding others that this state is 1076 bits long.
>
> I would in fact (strongly) prefer for this super accumulator to have
> quite a few guard bits! I.e. if I add & subtract a bunch of values then
> depending upon the order I might have a temporary overflow which
> wouldn't have happened with some other reduction order.
>
> How many would be enough?
>
> For sum reductions 32 extra bits would allow arbitrary ordering of at
> least a few billion items, so that's plenty. The additional cost of
> going to 1108 instead of 1076 bits seems miniscule.
> :-)

If My 66000 can have 32 arch registers doesn't that allow 32 FMA's for
cross-loop registers, plus per-loop registers are in addition to that,
to all be in-flight on an in-order core when that interrupt arrives?

So it could be looking at saving something like 64 * 1108 bits.

Or maybe I have misunderstood.

>
> We still need some (really fast!) storage if this resource needs to be
> interruptable, otherwise we would be left with a (memory-mapped?)
> accelerator which you would ask the OS to allocate to you for the
> duration, but with the additional cost that you would need to write all
> the results to this unit. That could still be OK if it is on-chip and
> can accept several store operations/cycle.
>
> Doing it this way removes the interruptability requirement, at the cost
> of needing a driver to handle arbitration.
>
> Terje
>

Re: VVM question

<9adc82bc-6754-4c05-99ba-b47ad811bcf2n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:486:: with SMTP id p6mr18308112qtx.340.1630269549693;
Sun, 29 Aug 2021 13:39:09 -0700 (PDT)
X-Received: by 2002:a54:4883:: with SMTP id r3mr13403607oic.7.1630269549457;
Sun, 29 Aug 2021 13:39:09 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fdn.fr!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: Sun, 29 Aug 2021 13:39:09 -0700 (PDT)
In-Reply-To: <K3SWI.442$7U3.268@fx24.iad>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <K3SWI.442$7U3.268@fx24.iad>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <9adc82bc-6754-4c05-99ba-b47ad811bcf2n@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 29 Aug 2021 20:39:09 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Sun, 29 Aug 2021 20:39 UTC

On Sunday, August 29, 2021 at 3:26:22 PM UTC-5, EricP wrote:
> Terje Mathisen wrote:
> > MitchAlsup wrote:
> >> On Friday, August 27, 2021 at 5:05:20 PM UTC-5, luke.l...@gmail.com
> >> wrote:
> >>> On Monday, August 23, 2021 at 10:55:26 PM UTC+1, MitchAlsup wrote:
> >>>
> >>>> The major problem is where does one store the state on an interrupt
> >>>> taken inside of the loop. I am letting my subconscious dwell on it
> >>>> right
> >>>> now.
> >> <
> >> Reminding others that this state is 1076 bits long.
> >
> > I would in fact (strongly) prefer for this super accumulator to have
> > quite a few guard bits! I.e. if I add & subtract a bunch of values then
> > depending upon the order I might have a temporary overflow which
> > wouldn't have happened with some other reduction order.
> >
> > How many would be enough?
> >
> > For sum reductions 32 extra bits would allow arbitrary ordering of at
> > least a few billion items, so that's plenty. The additional cost of
> > going to 1108 instead of 1076 bits seems miniscule.
> > :-)
<
> If My 66000 can have 32 arch registers doesn't that allow 32 FMA's for
> cross-loop registers, plus per-loop registers are in addition to that,
> to all be in-flight on an in-order core when that interrupt arrives?
<
An FMAC is 4 or 5 cycles of visible latency.
>
> So it could be looking at saving something like 64 * 1108 bits.
<
Building an accumulation of FMULs one might have 4 (or 8)
lanes of FMULs sending 4(|8)×106 bit products per cycle to a
single Accumulator which accumulates them into a 1076-bit
accumulator.
<
So, I only see 1 of these "big" registers per reduction.
<
What you want is to perform the calculation leading to the reduction
as wide as possible and then perform the accumulation of the reduction
as wide as possible to a single carry-save result per cycle. Whether
accumulation is AND, OR, XOR, IADD, UADD, FADD makes no real
difference to the accumulation.
>
> Or maybe I have misunderstood.
> >
> > We still need some (really fast!) storage if this resource needs to be
> > interruptable, otherwise we would be left with a (memory-mapped?)
> > accelerator which you would ask the OS to allocate to you for the
> > duration, but with the additional cost that you would need to write all
> > the results to this unit. That could still be OK if it is on-chip and
> > can accept several store operations/cycle.
> >
> > Doing it this way removes the interruptability requirement, at the cost
> > of needing a driver to handle arbitration.
> >
> > Terje
> >

Re: VVM question

<sggtvu$5ok$1@newsreader4.netcologne.de>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-22d2-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: VVM question
Date: Sun, 29 Aug 2021 21:25:18 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <sggtvu$5ok$1@newsreader4.netcologne.de>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de>
<3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <K3SWI.442$7U3.268@fx24.iad>
<9adc82bc-6754-4c05-99ba-b47ad811bcf2n@googlegroups.com>
Injection-Date: Sun, 29 Aug 2021 21:25:18 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-22d2-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:22d2:0:7285:c2ff:fe6c:992d";
logging-data="5908"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sun, 29 Aug 2021 21:25 UTC

MitchAlsup <MitchAlsup@aol.com> schrieb:

> What you want is to perform the calculation leading to the reduction
> as wide as possible and then perform the accumulation of the reduction
> as wide as possible to a single carry-save result per cycle. Whether
> accumulation is AND, OR, XOR, IADD, UADD, FADD makes no real
> difference to the accumulation.

Adding four or eight FMAC results into a single one... would the
carry-save adder also have to be the whole width? Anything
else might be too complicated, I guess.

If one result from the carry-save adder comes in every cycle,
I assume that final addition would also have to pipelined?

An, one other remark: The reduction in question could also be
a multiplication.

A 1076*106 bit multiplier sounds challenging...

Re: VVM question

<1b4b7d1a-989f-40d8-ab42-617b71ec8d6dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ae9:f50a:: with SMTP id o10mr20176880qkg.387.1630272866282;
Sun, 29 Aug 2021 14:34:26 -0700 (PDT)
X-Received: by 2002:a9d:1469:: with SMTP id h96mr16632229oth.82.1630272866079;
Sun, 29 Aug 2021 14:34:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.snarked.org!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 29 Aug 2021 14:34:25 -0700 (PDT)
In-Reply-To: <sggtvu$5ok$1@newsreader4.netcologne.de>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <K3SWI.442$7U3.268@fx24.iad>
<9adc82bc-6754-4c05-99ba-b47ad811bcf2n@googlegroups.com> <sggtvu$5ok$1@newsreader4.netcologne.de>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <1b4b7d1a-989f-40d8-ab42-617b71ec8d6dn@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 29 Aug 2021 21:34:26 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 29
 by: MitchAlsup - Sun, 29 Aug 2021 21:34 UTC

On Sunday, August 29, 2021 at 4:25:20 PM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > What you want is to perform the calculation leading to the reduction
> > as wide as possible and then perform the accumulation of the reduction
> > as wide as possible to a single carry-save result per cycle. Whether
> > accumulation is AND, OR, XOR, IADD, UADD, FADD makes no real
> > difference to the accumulation.
<
> Adding four or eight FMAC results into a single one... would the
> carry-save adder also have to be the whole width? Anything
> else might be too complicated, I guess.
<
Congratulations for your "Captain Obvious" remark.
>
> If one result from the carry-save adder comes in every cycle,
> I assume that final addition would also have to pipelined?
<
Addition, Normalization, and Rounding are all after the accumulate
stage. As are Underflow, Overflow,.....
>
> An, one other remark: The reduction in question could also be
> a multiplication.
<
No. Multiplication is NOT a reduction found in physics or math.
It is a producer of things to become reduced.
>
> A 1076*106 bit multiplier sounds challenging...

It is just 17×17 = 288 { 64*64 multiplications }.

Re: VVM question

<483a1b8c-6985-4ddf-86e5-72d138874e49n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:5805:: with SMTP id g5mr18231779qtg.360.1630273285411;
Sun, 29 Aug 2021 14:41:25 -0700 (PDT)
X-Received: by 2002:a9d:829:: with SMTP id 38mr17014401oty.342.1630273285153;
Sun, 29 Aug 2021 14:41:25 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.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: Sun, 29 Aug 2021 14:41:24 -0700 (PDT)
In-Reply-To: <sggpif$1pld$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=92.40.178.54; posting-account=soFpvwoAAADIBXOYOBcm_mixNPAaxW9p
NNTP-Posting-Host: 92.40.178.54
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <483a1b8c-6985-4ddf-86e5-72d138874e49n@googlegroups.com>
Subject: Re: VVM question
From: luke.lei...@gmail.com (luke.l...@gmail.com)
Injection-Date: Sun, 29 Aug 2021 21:41:25 +0000
Content-Type: text/plain; charset="UTF-8"
 by: luke.l...@gmail.com - Sun, 29 Aug 2021 21:41 UTC

On Sunday, August 29, 2021 at 9:09:58 PM UTC+1, Terje Mathisen wrote:

> We still need some (really fast!) storage if this resource needs to be
> interruptable, otherwise we would be left with a (memory-mapped?)
> accelerator which you would ask the OS to allocate to you for the
> duration, but with the additional cost that you would need to write all
> the results to this unit. That could still be OK if it is on-chip and
> can accept several store operations/cycle.

the typical way would be to have a batch of SPRs/CSRs
(special purpose / control status registers) each 64 bit,
the 1000-bit value is spread across multiple of them.

> Doing it this way removes the interruptability requirement, at the cost
> of needing a driver to handle arbitration.

if the contents were accessible via QTY 16 64 bit SPRs then save/restore
is a matter of LD/ST of 16 additional SPRs. it is a hell of a lot of state,
probably best done through conditional checking to see if the state is
actually in use.

in a Horizontal-First Vector ISA this problem does not occur, you simply
declare that the entire state in the Reduction Sum is to be thrown away, if
interrupted, and this is perfectly possible because Horizontal-First
Vectors *only* execute the one Vector instruction, in full, all elements,
before moving on to the next instruction.

Vertical-First you are a bit screwed: element-based accumulation
on one instruction, followed by others that have nothing to do
with the Reduction Sum, then round the loop again, can you "unwind"
the entire lot back to *before* the Reduction Sum started?
(by using Shadowing or Transaction snapshots)
maybe the answer there is yes.

that is still an awful lot of in-flight Shadowed state to be holding in buffers,
and, worse, a simple single-issue in-order system (one of the
supported designs of VVM) would not cope.

i think this is why in SVP64 we're supporting both Horizontal and
Vertical Vector Modes, because there are advantages (and disadvantages)
of each, and they complement each other.

l.

Re: VVM question

<sgh0gc$rru$1@dont-email.me>

 copy mid

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

 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: VVM question
Date: Sun, 29 Aug 2021 15:08:12 -0700
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <sgh0gc$rru$1@dont-email.me>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de>
<3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 29 Aug 2021 22:08:12 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="ebe52ec330f07c0fd0f31a33589d3605";
logging-data="28542"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18rVi0fm+WncNs0MXcv07zZd6yUxnSxvZc="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:7NTgiGfigziqR6TBL7t+DPNTjOs=
In-Reply-To: <sggpif$1pld$1@gioia.aioe.org>
Content-Language: en-US
 by: Stephen Fuld - Sun, 29 Aug 2021 22:08 UTC

On 8/29/2021 1:09 PM, Terje Mathisen wrote:
> MitchAlsup wrote:
>> On Friday, August 27, 2021 at 5:05:20 PM UTC-5, luke.l...@gmail.com
>> wrote:
>>> On Monday, August 23, 2021 at 10:55:26 PM UTC+1, MitchAlsup wrote:
>>>
>>>> The major problem is where does one store the state on an interrupt
>>>> taken inside of the loop. I am letting my subconscious dwell on it
>>>> right
>>>> now.
>> <
>> Reminding others that this state is 1076 bits long.
>
> I would in fact (strongly) prefer for this super accumulator to have
> quite a few guard bits! I.e. if I add & subtract a bunch of values then
> depending upon the order I might have a temporary overflow which
> wouldn't have happened with some other reduction order.
>
> How many would be enough?
>
> For sum reductions 32 extra bits would allow arbitrary ordering of at
> least a few billion items, so that's plenty. The additional cost of
> going to 1108 instead of 1076 bits seems miniscule.
> :-)
>
> We still need some (really fast!) storage if this resource needs to be
> interruptable, otherwise we would be left with a (memory-mapped?)
> accelerator which you would ask the OS to allocate to you for the
> duration, but with the additional cost that you would need to write all
> the results to this unit. That could still be OK if it is on-chip and
> can accept several store operations/cycle.
>
> Doing it this way removes the interruptability requirement, at the cost
> of needing a driver to handle arbitration.

I may be missing something, but why not have the space defined in the
the thread header, right after the area allocated for register saves.
(Adding an extra say 150 bytes per thread is insignificant.) You would
have a bit set to indicate whether the large accumulator is in use or
not (Carry meta instruction immediately proceeding the VEC
instruction?), so it would only need to be saved/restored if it was
actually in use. You might need variants of the load/store multiple to
indicate the accumulator as the target/source for the instruction. But
since the ISR isn't going to use the accumulator, the store can be lazy.
There is an extra time penalty to restart the thread using the
accumulator, but it should be pretty rare, and only hurts him. Thus, no
extra hardware (perhaps it uses some level of the cache, TBD), and no
driver required.

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

Re: VVM question

<c39eed78-db07-4020-a55b-ef7d293d8cb7n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a0c:8066:: with SMTP id 93mr20793522qva.52.1630276172831; Sun, 29 Aug 2021 15:29:32 -0700 (PDT)
X-Received: by 2002:a4a:3b0e:: with SMTP id s14mr7887785oos.40.1630276172612; Sun, 29 Aug 2021 15:29:32 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 29 Aug 2021 15:29:32 -0700 (PDT)
In-Reply-To: <483a1b8c-6985-4ddf-86e5-72d138874e49n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com> <sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com> <sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de> <sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com> <sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com> <b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com> <sggpif$1pld$1@gioia.aioe.org> <483a1b8c-6985-4ddf-86e5-72d138874e49n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c39eed78-db07-4020-a55b-ef7d293d8cb7n@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 29 Aug 2021 22:29:32 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 54
 by: MitchAlsup - Sun, 29 Aug 2021 22:29 UTC

On Sunday, August 29, 2021 at 4:41:26 PM UTC-5, luke.l...@gmail.com wrote:
> On Sunday, August 29, 2021 at 9:09:58 PM UTC+1, Terje Mathisen wrote:
>
> > We still need some (really fast!) storage if this resource needs to be
> > interruptable, otherwise we would be left with a (memory-mapped?)
> > accelerator which you would ask the OS to allocate to you for the
> > duration, but with the additional cost that you would need to write all
> > the results to this unit. That could still be OK if it is on-chip and
> > can accept several store operations/cycle.
<
> the typical way would be to have a batch of SPRs/CSRs
> (special purpose / control status registers) each 64 bit,
> the 1000-bit value is spread across multiple of them.
<
> > Doing it this way removes the interruptability requirement, at the cost
> > of needing a driver to handle arbitration.
<
> if the contents were accessible via QTY 16 64 bit SPRs then save/restore
> is a matter of LD/ST of 16 additional SPRs. it is a hell of a lot of state,
> probably best done through conditional checking to see if the state is
> actually in use.
>
> in a Horizontal-First Vector ISA this problem does not occur, you simply
> declare that the entire state in the Reduction Sum is to be thrown away, if
> interrupted, and this is perfectly possible because Horizontal-First
> Vectors *only* execute the one Vector instruction, in full, all elements,
> before moving on to the next instruction.
<
I should remind you that the reduction is over a loop of vectorized
calculations. You want the accurate reduction of 1B calculations,
not 64 (or whatever). So the problem does not exist for the H-F vector
but still remains for a loop of H-F vectors. How do you get the 1076
bits from the first loop into the accumulator for the 2nd, 3rd, 4th loops ?
>
> Vertical-First you are a bit screwed: element-based accumulation
> on one instruction, followed by others that have nothing to do
> with the Reduction Sum, then round the loop again, can you "unwind"
> the entire lot back to *before* the Reduction Sum started?
> (by using Shadowing or Transaction snapshots)
> maybe the answer there is yes.
<
Screwedness is the same. It just appears at slightly different boundaries.
>
> that is still an awful lot of in-flight Shadowed state to be holding in buffers,
> and, worse, a simple single-issue in-order system (one of the
> supported designs of VVM) would not cope.
<
Which is why I recognize the reduction problem but have not converged
to a implementable solution.
>
> i think this is why in SVP64 we're supporting both Horizontal and
> Vertical Vector Modes, because there are advantages (and disadvantages)
> of each, and they complement each other.
>
> l.

Re: VVM question

<dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:4b4c:: with SMTP id e12mr18544273qts.193.1630276227279;
Sun, 29 Aug 2021 15:30:27 -0700 (PDT)
X-Received: by 2002:a9d:7e88:: with SMTP id m8mr17235255otp.81.1630276227066;
Sun, 29 Aug 2021 15:30:27 -0700 (PDT)
Path: i2pn2.org!i2pn.org!news.niel.me!usenet.pasdenom.info!usenet-fr.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: Sun, 29 Aug 2021 15:30:26 -0700 (PDT)
In-Reply-To: <sgh0gc$rru$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=92.40.178.52; posting-account=soFpvwoAAADIBXOYOBcm_mixNPAaxW9p
NNTP-Posting-Host: 92.40.178.52
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com>
Subject: Re: VVM question
From: luke.lei...@gmail.com (luke.l...@gmail.com)
Injection-Date: Sun, 29 Aug 2021 22:30:27 +0000
Content-Type: text/plain; charset="UTF-8"
 by: luke.l...@gmail.com - Sun, 29 Aug 2021 22:30 UTC

On Sunday, August 29, 2021 at 11:08:15 PM UTC+1, Stephen Fuld wrote:

> I may be missing something, but why not have the space defined in the
> the thread header, right after the area allocated for register saves.
> (Adding an extra say 150 bytes per thread is insignificant.) You would
> have a bit set to indicate whether the large accumulator is in use or
> not (Carry meta instruction immediately proceeding the VEC
> instruction?), so it would only need to be saved/restored if it was
> actually in use.

funny, crossover, this is exactly the idea i suggested, too.
whether it be done CISC style (the hardware performs the save)
or RISC style (explicit instructions in the ISR) it is still quite
expensive. in the RISC case the ISR must always have at least
the insteuction testing the bit, plus a branch to jump over
the save.

i'm not seeing many other viable options though, if Vertical-Mode
is to be preserved in VVM and this feature added.

would it not be better to attempt long-integer math instead? support
both massive FP numbers spread across multiple GPRs as well
as big integer math, and do it that way?

l.

Re: VVM question

<ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:607:: with SMTP id 7mr20493491qkg.0.1630280156440;
Sun, 29 Aug 2021 16:35:56 -0700 (PDT)
X-Received: by 2002:a05:6808:1404:: with SMTP id w4mr20454764oiv.155.1630280156252;
Sun, 29 Aug 2021 16:35:56 -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: Sun, 29 Aug 2021 16:35:56 -0700 (PDT)
In-Reply-To: <dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me> <dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sun, 29 Aug 2021 23:35:56 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Sun, 29 Aug 2021 23:35 UTC

On Sunday, August 29, 2021 at 5:30:28 PM UTC-5, luke.l...@gmail.com wrote:
> On Sunday, August 29, 2021 at 11:08:15 PM UTC+1, Stephen Fuld wrote:
>
> > I may be missing something, but why not have the space defined in the
> > the thread header, right after the area allocated for register saves.
> > (Adding an extra say 150 bytes per thread is insignificant.) You would
> > have a bit set to indicate whether the large accumulator is in use or
> > not (Carry meta instruction immediately proceeding the VEC
> > instruction?), so it would only need to be saved/restored if it was
> > actually in use.
<
Currently, I have 320 bytes of Thread State (256 Bytes of which are registers).
I would like to put these things on 512Byte boundaries. Leaving 1536
bits left over. So, technically, one per thread(=process) would fit.
<
I have been using this space for Exception logout between the time of
raising an exception and when exception is processed by handler. But
nothing is in concrete yet. This logout allows a disabled exception to
logout the fact that an instruction raised this exception, and hold onto
it while the exception remains disabled. But when reEnabled, the enabled
and raised exception not only causes control transfer, but has data to
feed the handler.
<
> funny, crossover, this is exactly the idea i suggested, too.
> whether it be done CISC style (the hardware performs the save)
> or RISC style (explicit instructions in the ISR) it is still quite
> expensive. in the RISC case the ISR must always have at least
> the insteuction testing the bit, plus a branch to jump over
> the save.
<
Not just expensive in time, but in complexity.
>
> i'm not seeing many other viable options though, if Vertical-Mode
> is to be preserved in VVM and this feature added.
>
> would it not be better to attempt long-integer math instead? support
> both massive FP numbers spread across multiple GPRs as well
> as big integer math, and do it that way?
<
Kahan-Babbuška (IEEE 754-2019) summation is already in My 66000 ISA.
<
This in a numerical sense is being compared and contrasted with quires
in unums of which IEEE fails on a technical sense (numeric purity) and
wins on a practical sense (implementation difficulty).
>
> l.

Re: VVM question

<2021Aug30.174540@mips.complang.tuwien.ac.at>

 copy mid

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

 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: VVM question
Date: Mon, 30 Aug 2021 15:45:40 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 17
Distribution: world
Message-ID: <2021Aug30.174540@mips.complang.tuwien.ac.at>
References: <sftuaa$but$1@newsreader4.netcologne.de> <sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com> <sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com> <b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com> <sggpif$1pld$1@gioia.aioe.org> <K3SWI.442$7U3.268@fx24.iad> <9adc82bc-6754-4c05-99ba-b47ad811bcf2n@googlegroups.com> <sggtvu$5ok$1@newsreader4.netcologne.de>
Injection-Info: reader02.eternal-september.org; posting-host="a299dbf7380ba492227c2860e9027c9a";
logging-data="28199"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/XSKDaW3aWGqNvxtCR+eGV"
Cancel-Lock: sha1:QAJN2O28Ru/G/OaZ1+oZ/OZzN7c=
X-newsreader: xrn 10.00-beta-3
 by: Anton Ertl - Mon, 30 Aug 2021 15:45 UTC

Thomas Koenig <tkoenig@netcologne.de> writes:
>An, one other remark: The reduction in question could also be
>a multiplication.
>
>A 1076*106 bit multiplier sounds challenging...

Mitch Alsup pointed out that multiplicative reduction is rare.

One other aspect is that multiplication does not produce cancellation,
so there is no need for such a large accumulator. Exponent overflow
is much more likely to become a problem when you perform
multiplicative reduction on a large set of numbers.

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

Re: VVM question

<84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ae9:f50a:: with SMTP id o10mr24093631qkg.387.1630342716083; Mon, 30 Aug 2021 09:58:36 -0700 (PDT)
X-Received: by 2002:a9d:4e96:: with SMTP id v22mr19707510otk.110.1630342715896; Mon, 30 Aug 2021 09:58:35 -0700 (PDT)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 30 Aug 2021 09:58:35 -0700 (PDT)
In-Reply-To: <ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=217.147.94.29; posting-account=soFpvwoAAADIBXOYOBcm_mixNPAaxW9p
NNTP-Posting-Host: 217.147.94.29
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com> <sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com> <sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de> <sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com> <sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com> <b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com> <sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me> <dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com> <ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com>
Subject: Re: VVM question
From: luke.lei...@gmail.com (luke.l...@gmail.com)
Injection-Date: Mon, 30 Aug 2021 16:58:36 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 50
 by: luke.l...@gmail.com - Mon, 30 Aug 2021 16:58 UTC

On Monday, August 30, 2021 at 12:35:57 AM UTC+1, MitchAlsup wrote:

> I have been using this space for Exception logout between the time of
> raising an exception and when exception is processed by handler. But
> nothing is in concrete yet. This logout allows a disabled exception to
> logout the fact that an instruction raised this exception, and hold onto
> it while the exception remains disabled. But when reEnabled, the enabled
> and raised exception not only causes control transfer, but has data to
> feed the handler.

you will perhaps be either fascinated or amused that i could read the
words but they melted my brain and i couldn't understand it.
perhaps because i lack context? if you'd like to use that as an
opportunity to clarify things i'm more than happy to hear further
elaboration.

> <
> > funny, crossover, this is exactly the idea i suggested, too.
> > whether it be done CISC style (the hardware performs the save)
> > or RISC style (explicit instructions in the ISR) it is still quite
> > expensive. in the RISC case the ISR must always have at least
> > the insteuction testing the bit, plus a branch to jump over
> > the save.
> <
> Not just expensive in time, but in complexity.
> >
> > i'm not seeing many other viable options though, if Vertical-Mode
> > is to be preserved in VVM and this feature added.
> >
> > would it not be better to attempt long-integer math instead? support
> > both massive FP numbers spread across multiple GPRs as well
> > as big integer math, and do it that way?
> <
> Kahan-Babbuška (IEEE 754-2019) summation is already in My 66000 ISA.

https://en.wikipedia.org/wiki/Kahan_summation_algorithm

interesting. so the intermediate result is created, but the remainder
is lost. *however*, by *subtracting* the intermediate result from the
current sum, the difference (which may be quite small) is dropped
into a secondary accumulator.

nice trick.

is that being applied at a hardware level or as an expected algorithm to be
used in software?

l.

Re: VVM question

<sgj4j3$73m$1@dont-email.me>

 copy mid

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

 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: VVM question
Date: Mon, 30 Aug 2021 10:30:09 -0700
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <sgj4j3$73m$1@dont-email.me>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de>
<3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me>
<dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com>
<ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 30 Aug 2021 17:30:11 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="22d4c611e206d1b1b0100bda94568873";
logging-data="7286"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19nr2zPcvpsoFpy7EXylbn5P72CHroxd4Q="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:RgYHlje+niYZMZPzdFm8wGr2QBs=
In-Reply-To: <ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
Content-Language: en-US
 by: Stephen Fuld - Mon, 30 Aug 2021 17:30 UTC

On 8/29/2021 4:35 PM, MitchAlsup wrote:
> On Sunday, August 29, 2021 at 5:30:28 PM UTC-5, luke.l...@gmail.com wrote:
>> On Sunday, August 29, 2021 at 11:08:15 PM UTC+1, Stephen Fuld wrote:
>>
>>> I may be missing something, but why not have the space defined in the
>>> the thread header, right after the area allocated for register saves.
>>> (Adding an extra say 150 bytes per thread is insignificant.) You would
>>> have a bit set to indicate whether the large accumulator is in use or
>>> not (Carry meta instruction immediately proceeding the VEC
>>> instruction?), so it would only need to be saved/restored if it was
>>> actually in use.
> <
> Currently, I have 320 bytes of Thread State (256 Bytes of which are registers).
> I would like to put these things on 512Byte boundaries. Leaving 1536
> bits left over. So, technically, one per thread(=process) would fit.
> <
> I have been using this space for Exception logout between the time of
> raising an exception and when exception is processed by handler. But
> nothing is in concrete yet. This logout allows a disabled exception to
> logout the fact that an instruction raised this exception, and hold onto
> it while the exception remains disabled. But when reEnabled, the enabled
> and raised exception not only causes control transfer, but has data to
> feed the handler.

OK, that is certainly reasonable, but I am not sure that it is a
problem. At first blush, the space's use as a save area for the
accumulator only occurs when the using thread is being switched out,
which means that, by definition, exceptions weren't disabled. The
thread using it will then not be active, so it can't take an exception.
So I think you can use the same space for both uses, as long as you
have a bit in there somewhere to indicate which use is the current one.

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

Re: VVM question

<ca8d2781-fddd-4756-a453-16279c2aa745n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:1239:: with SMTP id v25mr8122816qkj.202.1630345523742;
Mon, 30 Aug 2021 10:45:23 -0700 (PDT)
X-Received: by 2002:a05:6808:f90:: with SMTP id o16mr210569oiw.37.1630345523455;
Mon, 30 Aug 2021 10:45:23 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!usenet.pasdenom.info!usenet-fr.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, 30 Aug 2021 10:45:23 -0700 (PDT)
In-Reply-To: <84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me>
<dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com> <ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
<84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ca8d2781-fddd-4756-a453-16279c2aa745n@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 30 Aug 2021 17:45:23 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Mon, 30 Aug 2021 17:45 UTC

On Monday, August 30, 2021 at 11:58:37 AM UTC-5, luke.l...@gmail.com wrote:
> On Monday, August 30, 2021 at 12:35:57 AM UTC+1, MitchAlsup wrote:
>
> > I have been using this space for Exception logout between the time of
> > raising an exception and when exception is processed by handler. But
> > nothing is in concrete yet. This logout allows a disabled exception to
> > logout the fact that an instruction raised this exception, and hold onto
> > it while the exception remains disabled. But when reEnabled, the enabled
> > and raised exception not only causes control transfer, but has data to
> > feed the handler.
<
> you will perhaps be either fascinated or amused that i could read the
> words but they melted my brain and i couldn't understand it.
> perhaps because i lack context? if you'd like to use that as an
> opportunity to clarify things i'm more than happy to hear further
> elaboration.
<
I use the word Thread whereas most Unix/Linux would use the
word process. A Thread in my nomenclature can be a u/l thread
under a process, a process itself, or an OS thread servicing the
process. A Thread contains a Root Pointer to memory mapping
tables, and contains State: PSW, register file, an Exception Raised
register and an Exception Enabled Register. These later 2 enable the
Thread to control when he takes exception control transfer.
<
When an Exception is Raised, a bit of state is stored so the
Exception Handler, when it runs, knows what to do. That an
exception was raised is recorded in the Raised register,
What caused the exception, where it was caused, is recorded
elsewhere. Right now this elsewhere is concatenated to the
area containing the Thread State; it could be moved elsewhere.
IP (in Thread State) points at the offending instruction,...
> > <
> > > funny, crossover, this is exactly the idea i suggested, too.
> > > whether it be done CISC style (the hardware performs the save)
> > > or RISC style (explicit instructions in the ISR) it is still quite
> > > expensive. in the RISC case the ISR must always have at least
> > > the insteuction testing the bit, plus a branch to jump over
> > > the save.
> > <
> > Not just expensive in time, but in complexity.
> > >
> > > i'm not seeing many other viable options though, if Vertical-Mode
> > > is to be preserved in VVM and this feature added.
> > >
> > > would it not be better to attempt long-integer math instead? support
> > > both massive FP numbers spread across multiple GPRs as well
> > > as big integer math, and do it that way?
> > <
> > Kahan-Babbuška (IEEE 754-2019) summation is already in My 66000 ISA.
> https://en.wikipedia.org/wiki/Kahan_summation_algorithm
>
> interesting. so the intermediate result is created, but the remainder
> is lost. *however*, by *subtracting* the intermediate result from the
> current sum, the difference (which may be quite small) is dropped
> into a secondary accumulator.
>
> nice trick.
>
> is that being applied at a hardware level or as an expected algorithm to be
> used in software?
<
Kahan-Babbuška summation in My 66000 is 1 instruction-modifier,
and 1 FMAC instruction. It is easier in HW to do these things than in SW.
>
> l.

Re: VVM question

<4207a9cb-1e27-48cd-8a68-d2aeb7655d0fn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:525:: with SMTP id x5mr23430155qvw.8.1630345817268;
Mon, 30 Aug 2021 10:50:17 -0700 (PDT)
X-Received: by 2002:a05:6808:10c8:: with SMTP id s8mr208938ois.175.1630345817082;
Mon, 30 Aug 2021 10:50:17 -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, 30 Aug 2021 10:50:16 -0700 (PDT)
In-Reply-To: <sgj4j3$73m$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me>
<dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com> <ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
<sgj4j3$73m$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <4207a9cb-1e27-48cd-8a68-d2aeb7655d0fn@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 30 Aug 2021 17:50:17 +0000
Content-Type: text/plain; charset="UTF-8"
 by: MitchAlsup - Mon, 30 Aug 2021 17:50 UTC

On Monday, August 30, 2021 at 12:30:13 PM UTC-5, Stephen Fuld wrote:
> On 8/29/2021 4:35 PM, MitchAlsup wrote:
> > On Sunday, August 29, 2021 at 5:30:28 PM UTC-5, luke.l...@gmail.com wrote:
> >> On Sunday, August 29, 2021 at 11:08:15 PM UTC+1, Stephen Fuld wrote:
> >>
> >>> I may be missing something, but why not have the space defined in the
> >>> the thread header, right after the area allocated for register saves.
> >>> (Adding an extra say 150 bytes per thread is insignificant.) You would
> >>> have a bit set to indicate whether the large accumulator is in use or
> >>> not (Carry meta instruction immediately proceeding the VEC
> >>> instruction?), so it would only need to be saved/restored if it was
> >>> actually in use.
> > <
> > Currently, I have 320 bytes of Thread State (256 Bytes of which are registers).
> > I would like to put these things on 512Byte boundaries. Leaving 1536
> > bits left over. So, technically, one per thread(=process) would fit.
> > <
> > I have been using this space for Exception logout between the time of
> > raising an exception and when exception is processed by handler. But
> > nothing is in concrete yet. This logout allows a disabled exception to
> > logout the fact that an instruction raised this exception, and hold onto
> > it while the exception remains disabled. But when reEnabled, the enabled
> > and raised exception not only causes control transfer, but has data to
> > feed the handler.
<
> OK, that is certainly reasonable, but I am not sure that it is a
> problem. At first blush, the space's use as a save area for the
> accumulator only occurs when the using thread is being switched out,
> which means that, by definition, exceptions weren't disabled. The
> thread using it will then not be active, so it can't take an exception.
> So I think you can use the same space for both uses, as long as you
> have a bit in there somewhere to indicate which use is the current one.
<
Yes, as far as HW exceptions are concerned. Software can also "throw"
exceptions at a Thread, Inter Processor Communication in an instruction.
<
I am slowly grinding towards using a slight superset of these mechanisms
to support ADA-style rendezvous mostly in HW. For these purposes I
need a "message" space of at least 8 doublewords forward and backward
through the call-accept boundary.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Re: VVM question

<sgjebq$9jf$1@dont-email.me>

 copy mid

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

 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: VVM question
Date: Mon, 30 Aug 2021 13:16:58 -0700
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <sgjebq$9jf$1@dont-email.me>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <K3SWI.442$7U3.268@fx24.iad>
<9adc82bc-6754-4c05-99ba-b47ad811bcf2n@googlegroups.com>
<sggtvu$5ok$1@newsreader4.netcologne.de>
<2021Aug30.174540@mips.complang.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 30 Aug 2021 20:16:58 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4df7050554dd6e9f39923c89d95a7082";
logging-data="9839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1985e7rnzQIGJLt9CXvUJCQ"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:t+X3pSgzWpLxc8LJj0x7IzOPXKE=
In-Reply-To: <2021Aug30.174540@mips.complang.tuwien.ac.at>
Content-Language: en-US
 by: Ivan Godard - Mon, 30 Aug 2021 20:16 UTC

On 8/30/2021 8:45 AM, Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> An, one other remark: The reduction in question could also be
>> a multiplication.
>>
>> A 1076*106 bit multiplier sounds challenging...
>
> Mitch Alsup pointed out that multiplicative reduction is rare.
>
> One other aspect is that multiplication does not produce cancellation,
> so there is no need for such a large accumulator. Exponent overflow
> is much more likely to become a problem when you perform
> multiplicative reduction on a large set of numbers.
>
> - anton
>

Underflow too; denorms have their own issues.

Re: VVM question

<sgjeg3$9jf$2@dont-email.me>

 copy mid

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

 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: VVM question
Date: Mon, 30 Aug 2021 13:19:15 -0700
Organization: A noiseless patient Spider
Lines: 51
Message-ID: <sgjeg3$9jf$2@dont-email.me>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de>
<3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me>
<dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com>
<ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
<84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 30 Aug 2021 20:19:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4df7050554dd6e9f39923c89d95a7082";
logging-data="9839"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+C3TJsozMLdS4lT2ka4zgX"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:Q/ZV0Rkht673x5YNlTyM5GoZHRY=
In-Reply-To: <84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 30 Aug 2021 20:19 UTC

On 8/30/2021 9:58 AM, luke.l...@gmail.com wrote:
> On Monday, August 30, 2021 at 12:35:57 AM UTC+1, MitchAlsup wrote:
>
>> I have been using this space for Exception logout between the time of
>> raising an exception and when exception is processed by handler. But
>> nothing is in concrete yet. This logout allows a disabled exception to
>> logout the fact that an instruction raised this exception, and hold onto
>> it while the exception remains disabled. But when reEnabled, the enabled
>> and raised exception not only causes control transfer, but has data to
>> feed the handler.
>
> you will perhaps be either fascinated or amused that i could read the
> words but they melted my brain and i couldn't understand it.
> perhaps because i lack context? if you'd like to use that as an
> opportunity to clarify things i'm more than happy to hear further
> elaboration.
>
>> <
>>> funny, crossover, this is exactly the idea i suggested, too.
>>> whether it be done CISC style (the hardware performs the save)
>>> or RISC style (explicit instructions in the ISR) it is still quite
>>> expensive. in the RISC case the ISR must always have at least
>>> the insteuction testing the bit, plus a branch to jump over
>>> the save.
>> <
>> Not just expensive in time, but in complexity.
>>>
>>> i'm not seeing many other viable options though, if Vertical-Mode
>>> is to be preserved in VVM and this feature added.
>>>
>>> would it not be better to attempt long-integer math instead? support
>>> both massive FP numbers spread across multiple GPRs as well
>>> as big integer math, and do it that way?
>> <
>> Kahan-Babbuška (IEEE 754-2019) summation is already in My 66000 ISA.
>
> https://en.wikipedia.org/wiki/Kahan_summation_algorithm
>
> interesting. so the intermediate result is created, but the remainder
> is lost. *however*, by *subtracting* the intermediate result from the
> current sum, the difference (which may be quite small) is dropped
> into a secondary accumulator.
>
> nice trick.
>
> is that being applied at a hardware level or as an expected algorithm to be
> used in software?

Some hardware. The problem for most ISAs is the paired result, with the
write-port consequences.

Re: VVM question

<ea7caf5f-7709-4f88-bf64-7b50e0f034fbn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:314:: with SMTP id 20mr24271680qkd.104.1630360886274; Mon, 30 Aug 2021 15:01:26 -0700 (PDT)
X-Received: by 2002:a4a:2c49:: with SMTP id o70mr11664362ooo.71.1630360886056; Mon, 30 Aug 2021 15:01:26 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 30 Aug 2021 15:01:25 -0700 (PDT)
In-Reply-To: <sgjeg3$9jf$2@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com> <sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com> <sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de> <sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com> <sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com> <b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com> <sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me> <dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com> <ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com> <84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com> <sgjeg3$9jf$2@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ea7caf5f-7709-4f88-bf64-7b50e0f034fbn@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 30 Aug 2021 22:01:26 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 67
 by: MitchAlsup - Mon, 30 Aug 2021 22:01 UTC

On Monday, August 30, 2021 at 1:19:17 PM UTC-7, Ivan Godard wrote:
> On 8/30/2021 9:58 AM, luke.l...@gmail.com wrote:
> > On Monday, August 30, 2021 at 12:35:57 AM UTC+1, MitchAlsup wrote:
> >
> >> I have been using this space for Exception logout between the time of
> >> raising an exception and when exception is processed by handler. But
> >> nothing is in concrete yet. This logout allows a disabled exception to
> >> logout the fact that an instruction raised this exception, and hold onto
> >> it while the exception remains disabled. But when reEnabled, the enabled
> >> and raised exception not only causes control transfer, but has data to
> >> feed the handler.
> >
> > you will perhaps be either fascinated or amused that i could read the
> > words but they melted my brain and i couldn't understand it.
> > perhaps because i lack context? if you'd like to use that as an
> > opportunity to clarify things i'm more than happy to hear further
> > elaboration.
> >
> >> <
> >>> funny, crossover, this is exactly the idea i suggested, too.
> >>> whether it be done CISC style (the hardware performs the save)
> >>> or RISC style (explicit instructions in the ISR) it is still quite
> >>> expensive. in the RISC case the ISR must always have at least
> >>> the insteuction testing the bit, plus a branch to jump over
> >>> the save.
> >> <
> >> Not just expensive in time, but in complexity.
> >>>
> >>> i'm not seeing many other viable options though, if Vertical-Mode
> >>> is to be preserved in VVM and this feature added.
> >>>
> >>> would it not be better to attempt long-integer math instead? support
> >>> both massive FP numbers spread across multiple GPRs as well
> >>> as big integer math, and do it that way?
> >> <
> >> Kahan-Babbuška (IEEE 754-2019) summation is already in My 66000 ISA.
> >
> > https://en.wikipedia.org/wiki/Kahan_summation_algorithm
> >
> > interesting. so the intermediate result is created, but the remainder
> > is lost. *however*, by *subtracting* the intermediate result from the
> > current sum, the difference (which may be quite small) is dropped
> > into a secondary accumulator.
> >
> > nice trick.
> >
> > is that being applied at a hardware level or as an expected algorithm to be
> > used in software?
<
> Some hardware. The problem for most ISAs is the paired result, with the
> write-port consequences.
<
But in My 66000, the functionality is accessed through CARRY which provides
the second operand input and provides a register for to additional result.
No pairing or sharing.

Re: VVM question

<sgjlks$qno$1@dont-email.me>

 copy mid

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

 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: VVM question
Date: Mon, 30 Aug 2021 15:21:17 -0700
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <sgjlks$qno$1@dont-email.me>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de>
<3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me>
<dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com>
<ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
<84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com>
<sgjeg3$9jf$2@dont-email.me>
<ea7caf5f-7709-4f88-bf64-7b50e0f034fbn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 30 Aug 2021 22:21:16 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="d5983455188be245b0cfbd9996372761";
logging-data="27384"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19kCjuA5Pw8uyWY5oMVyZLa"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:L79qRIWp1HVJfozpT+YKvnfGSSM=
In-Reply-To: <ea7caf5f-7709-4f88-bf64-7b50e0f034fbn@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Mon, 30 Aug 2021 22:21 UTC

On 8/30/2021 3:01 PM, MitchAlsup wrote:
> On Monday, August 30, 2021 at 1:19:17 PM UTC-7, Ivan Godard wrote:
>> On 8/30/2021 9:58 AM, luke.l...@gmail.com wrote:
>>> On Monday, August 30, 2021 at 12:35:57 AM UTC+1, MitchAlsup wrote:
>>>
>>>> I have been using this space for Exception logout between the time of
>>>> raising an exception and when exception is processed by handler. But
>>>> nothing is in concrete yet. This logout allows a disabled exception to
>>>> logout the fact that an instruction raised this exception, and hold onto
>>>> it while the exception remains disabled. But when reEnabled, the enabled
>>>> and raised exception not only causes control transfer, but has data to
>>>> feed the handler.
>>>
>>> you will perhaps be either fascinated or amused that i could read the
>>> words but they melted my brain and i couldn't understand it.
>>> perhaps because i lack context? if you'd like to use that as an
>>> opportunity to clarify things i'm more than happy to hear further
>>> elaboration.
>>>
>>>> <
>>>>> funny, crossover, this is exactly the idea i suggested, too.
>>>>> whether it be done CISC style (the hardware performs the save)
>>>>> or RISC style (explicit instructions in the ISR) it is still quite
>>>>> expensive. in the RISC case the ISR must always have at least
>>>>> the insteuction testing the bit, plus a branch to jump over
>>>>> the save.
>>>> <
>>>> Not just expensive in time, but in complexity.
>>>>>
>>>>> i'm not seeing many other viable options though, if Vertical-Mode
>>>>> is to be preserved in VVM and this feature added.
>>>>>
>>>>> would it not be better to attempt long-integer math instead? support
>>>>> both massive FP numbers spread across multiple GPRs as well
>>>>> as big integer math, and do it that way?
>>>> <
>>>> Kahan-Babbuška (IEEE 754-2019) summation is already in My 66000 ISA.
>>>
>>> https://en.wikipedia.org/wiki/Kahan_summation_algorithm
>>>
>>> interesting. so the intermediate result is created, but the remainder
>>> is lost. *however*, by *subtracting* the intermediate result from the
>>> current sum, the difference (which may be quite small) is dropped
>>> into a secondary accumulator.
>>>
>>> nice trick.
>>>
>>> is that being applied at a hardware level or as an expected algorithm to be
>>> used in software?
> <
>> Some hardware. The problem for most ISAs is the paired result, with the
>> write-port consequences.
> <
> But in My 66000, the functionality is accessed through CARRY which provides
> the second operand input and provides a register for to additional result.
> No pairing or sharing.
>

Er - "some"?

Re: VVM question

<7988670c-e266-4bfb-a663-c970509c174fn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ac8:7f51:: with SMTP id g17mr500053qtk.16.1630372932787;
Mon, 30 Aug 2021 18:22:12 -0700 (PDT)
X-Received: by 2002:a05:6808:14c5:: with SMTP id f5mr1412827oiw.84.1630372932501;
Mon, 30 Aug 2021 18:22:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!feeder.erje.net!fdn.fr!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, 30 Aug 2021 18:22:12 -0700 (PDT)
In-Reply-To: <sgjlks$qno$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=104.59.204.55; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 104.59.204.55
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me> <65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de> <64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com> <2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me>
<dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com> <ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
<84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com> <sgjeg3$9jf$2@dont-email.me>
<ea7caf5f-7709-4f88-bf64-7b50e0f034fbn@googlegroups.com> <sgjlks$qno$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <7988670c-e266-4bfb-a663-c970509c174fn@googlegroups.com>
Subject: Re: VVM question
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 31 Aug 2021 01:22:12 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Tue, 31 Aug 2021 01:22 UTC

On Monday, August 30, 2021 at 5:21:19 PM UTC-5, Ivan Godard wrote:
> On 8/30/2021 3:01 PM, MitchAlsup wrote:
> > On Monday, August 30, 2021 at 1:19:17 PM UTC-7, Ivan Godard wrote:
> >> On 8/30/2021 9:58 AM, luke.l...@gmail.com wrote:
> >>> On Monday, August 30, 2021 at 12:35:57 AM UTC+1, MitchAlsup wrote:
> >>>
> >>>> I have been using this space for Exception logout between the time of
> >>>> raising an exception and when exception is processed by handler. But
> >>>> nothing is in concrete yet. This logout allows a disabled exception to
> >>>> logout the fact that an instruction raised this exception, and hold onto
> >>>> it while the exception remains disabled. But when reEnabled, the enabled
> >>>> and raised exception not only causes control transfer, but has data to
> >>>> feed the handler.
> >>>
> >>> you will perhaps be either fascinated or amused that i could read the
> >>> words but they melted my brain and i couldn't understand it.
> >>> perhaps because i lack context? if you'd like to use that as an
> >>> opportunity to clarify things i'm more than happy to hear further
> >>> elaboration.
> >>>
> >>>> <
> >>>>> funny, crossover, this is exactly the idea i suggested, too.
> >>>>> whether it be done CISC style (the hardware performs the save)
> >>>>> or RISC style (explicit instructions in the ISR) it is still quite
> >>>>> expensive. in the RISC case the ISR must always have at least
> >>>>> the insteuction testing the bit, plus a branch to jump over
> >>>>> the save.
> >>>> <
> >>>> Not just expensive in time, but in complexity.
> >>>>>
> >>>>> i'm not seeing many other viable options though, if Vertical-Mode
> >>>>> is to be preserved in VVM and this feature added.
> >>>>>
> >>>>> would it not be better to attempt long-integer math instead? support
> >>>>> both massive FP numbers spread across multiple GPRs as well
> >>>>> as big integer math, and do it that way?
> >>>> <
> >>>> Kahan-Babbuška (IEEE 754-2019) summation is already in My 66000 ISA.
> >>>
> >>> https://en.wikipedia.org/wiki/Kahan_summation_algorithm
> >>>
> >>> interesting. so the intermediate result is created, but the remainder
> >>> is lost. *however*, by *subtracting* the intermediate result from the
> >>> current sum, the difference (which may be quite small) is dropped
> >>> into a secondary accumulator.
> >>>
> >>> nice trick.
> >>>
> >>> is that being applied at a hardware level or as an expected algorithm to be
> >>> used in software?
> > <
> >> Some hardware. The problem for most ISAs is the paired result, with the
> >> write-port consequences.
> > <
> > But in My 66000, the functionality is accessed through CARRY which provides
> > the second operand input and provides a register for to additional result.
> > No pairing or sharing.
> >
> Er - "some"?
<
Well the registers are not paired, nor are they shared.
<
The registers are not paired because the registers can just as easily be R9,R23
as R5,R6; this holds for both operands and results.
<
The registers are not shared because the CARRY supplied register is used for both
operand and result.

Re: VVM question

<sgk58p$8fo$1@dont-email.me>

 copy mid

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

 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: VVM question
Date: Mon, 30 Aug 2021 19:47:51 -0700
Organization: A noiseless patient Spider
Lines: 73
Message-ID: <sgk58p$8fo$1@dont-email.me>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de>
<3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <sgh0gc$rru$1@dont-email.me>
<dffa1454-c13a-4846-9f0d-72afd9ed62b0n@googlegroups.com>
<ab9989e9-8b7f-4f9f-b418-7874bf3d8715n@googlegroups.com>
<84d16aeb-4ea3-471f-be19-ce75aec06d2dn@googlegroups.com>
<sgjeg3$9jf$2@dont-email.me>
<ea7caf5f-7709-4f88-bf64-7b50e0f034fbn@googlegroups.com>
<sgjlks$qno$1@dont-email.me>
<7988670c-e266-4bfb-a663-c970509c174fn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 31 Aug 2021 02:47:53 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="d5983455188be245b0cfbd9996372761";
logging-data="8696"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+rtILMt+V4NBeUCCCantez"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.13.0
Cancel-Lock: sha1:vMrHEHo3cfGgRf0B2OtcgiS49QM=
In-Reply-To: <7988670c-e266-4bfb-a663-c970509c174fn@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Tue, 31 Aug 2021 02:47 UTC

On 8/30/2021 6:22 PM, MitchAlsup wrote:
> On Monday, August 30, 2021 at 5:21:19 PM UTC-5, Ivan Godard wrote:
>> On 8/30/2021 3:01 PM, MitchAlsup wrote:
>>> On Monday, August 30, 2021 at 1:19:17 PM UTC-7, Ivan Godard wrote:
>>>> On 8/30/2021 9:58 AM, luke.l...@gmail.com wrote:
>>>>> On Monday, August 30, 2021 at 12:35:57 AM UTC+1, MitchAlsup wrote:
>>>>>
>>>>>> I have been using this space for Exception logout between the time of
>>>>>> raising an exception and when exception is processed by handler. But
>>>>>> nothing is in concrete yet. This logout allows a disabled exception to
>>>>>> logout the fact that an instruction raised this exception, and hold onto
>>>>>> it while the exception remains disabled. But when reEnabled, the enabled
>>>>>> and raised exception not only causes control transfer, but has data to
>>>>>> feed the handler.
>>>>>
>>>>> you will perhaps be either fascinated or amused that i could read the
>>>>> words but they melted my brain and i couldn't understand it.
>>>>> perhaps because i lack context? if you'd like to use that as an
>>>>> opportunity to clarify things i'm more than happy to hear further
>>>>> elaboration.
>>>>>
>>>>>> <
>>>>>>> funny, crossover, this is exactly the idea i suggested, too.
>>>>>>> whether it be done CISC style (the hardware performs the save)
>>>>>>> or RISC style (explicit instructions in the ISR) it is still quite
>>>>>>> expensive. in the RISC case the ISR must always have at least
>>>>>>> the insteuction testing the bit, plus a branch to jump over
>>>>>>> the save.
>>>>>> <
>>>>>> Not just expensive in time, but in complexity.
>>>>>>>
>>>>>>> i'm not seeing many other viable options though, if Vertical-Mode
>>>>>>> is to be preserved in VVM and this feature added.
>>>>>>>
>>>>>>> would it not be better to attempt long-integer math instead? support
>>>>>>> both massive FP numbers spread across multiple GPRs as well
>>>>>>> as big integer math, and do it that way?
>>>>>> <
>>>>>> Kahan-Babbuška (IEEE 754-2019) summation is already in My 66000 ISA.
>>>>>
>>>>> https://en.wikipedia.org/wiki/Kahan_summation_algorithm
>>>>>
>>>>> interesting. so the intermediate result is created, but the remainder
>>>>> is lost. *however*, by *subtracting* the intermediate result from the
>>>>> current sum, the difference (which may be quite small) is dropped
>>>>> into a secondary accumulator.
>>>>>
>>>>> nice trick.
>>>>>
>>>>> is that being applied at a hardware level or as an expected algorithm to be
>>>>> used in software?
>>> <
>>>> Some hardware. The problem for most ISAs is the paired result, with the
>>>> write-port consequences.
>>> <
>>> But in My 66000, the functionality is accessed through CARRY which provides
>>> the second operand input and provides a register for to additional result.
>>> No pairing or sharing.
>>>
>> Er - "some"?
> <
> Well the registers are not paired, nor are they shared.
> <
> The registers are not paired because the registers can just as easily be R9,R23
> as R5,R6; this holds for both operands and results.
> <
> The registers are not shared because the CARRY supplied register is used for both
> operand and result.
>

Terminology :-( Talking about the datapath issue of multidrop, not about
the encoding issue of register pairs; sorry. You and I both ("some")
have multidrop, but it's a complication widely omitted.

Re: VVM question

<sgkj1c$kql$1@newsreader4.netcologne.de>

 copy mid

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

 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-22d2-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: VVM question
Date: Tue, 31 Aug 2021 06:42:52 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <sgkj1c$kql$1@newsreader4.netcologne.de>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de>
<3ae800da-d7d8-4437-b5bb-ec651b5f5700n@googlegroups.com>
<sg0gr4$pet$1@dont-email.me> <sg0n5u$74p$2@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <K3SWI.442$7U3.268@fx24.iad>
<9adc82bc-6754-4c05-99ba-b47ad811bcf2n@googlegroups.com>
<sggtvu$5ok$1@newsreader4.netcologne.de>
<1b4b7d1a-989f-40d8-ab42-617b71ec8d6dn@googlegroups.com>
Injection-Date: Tue, 31 Aug 2021 06:42:52 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-22d2-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:22d2:0:7285:c2ff:fe6c:992d";
logging-data="21333"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Tue, 31 Aug 2021 06:42 UTC

MitchAlsup <MitchAlsup@aol.com> schrieb:

> No. Multiplication is NOT a reduction found in physics or math.
> It is a producer of things to become reduced.

It's at least found in the OpenMP specs
https://www.openmp.org/spec-html/5.0/openmpsu107.html
(which does not mean that it is used frequently).

Re: VVM question

<sgkml1$jhf$1@gioia.aioe.org>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!aioe.org!ppYixYMWAWh/woI8emJOIQ.user.46.165.242.91.POSTED!not-for-mail
From: terje.ma...@tmsw.no (Terje Mathisen)
Newsgroups: comp.arch
Subject: Re: VVM question
Date: Tue, 31 Aug 2021 09:44:31 +0200
Organization: Aioe.org NNTP Server
Message-ID: <sgkml1$jhf$1@gioia.aioe.org>
References: <sftuaa$but$1@newsreader4.netcologne.de>
<sg0omd$itq$1@dont-email.me>
<65bad170-8d27-4ad4-bf8f-69157e6869f2n@googlegroups.com>
<sg13vd$hom$1@newsreader4.netcologne.de>
<64fe2d82-96f7-4c94-9b0c-aa05605c3fcen@googlegroups.com>
<b39bc6eb-2d43-45a3-b15f-bf6452e311a6n@googlegroups.com>
<2e6e65bf-493a-4d8d-8c3e-9d0af174109bn@googlegroups.com>
<sggpif$1pld$1@gioia.aioe.org> <K3SWI.442$7U3.268@fx24.iad>
<9adc82bc-6754-4c05-99ba-b47ad811bcf2n@googlegroups.com>
<sggtvu$5ok$1@newsreader4.netcologne.de>
<2021Aug30.174540@mips.complang.tuwien.ac.at> <sgjebq$9jf$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="20015"; posting-host="ppYixYMWAWh/woI8emJOIQ.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.9
X-Notice: Filtered by postfilter v. 0.9.2
 by: Terje Mathisen - Tue, 31 Aug 2021 07:44 UTC

Ivan Godard wrote:
> On 8/30/2021 8:45 AM, Anton Ertl wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> An, one other remark: The reduction in question could also be
>>> a multiplication.
>>>
>>> A 1076*106 bit multiplier sounds challenging...
>>
>> Mitch Alsup pointed out that multiplicative reduction is rare.
>>
>> One other aspect is that multiplication does not produce cancellation,
>> so there is no need for such a large accumulator.  Exponent overflow
>> is much more likely to become a problem when you perform
>> multiplicative reduction on a large set of numbers.
>>
>> - anton
>>
>
> Underflow too; denorms have their own issues.

Not really for a super-accumulator: You just align the mantissa bits,
based on the exponent (inserting the hidden bit unless the exponent is
zero), and from then on there's just the carry-save full adder array.

The actual 53-bit input aligner with a ~1100 bit target is a substantial
piece of hardware, the shifter from the deep lagoon. :-)

This is the point where I expect Mitch to pipe in and say that it is
only 3-5 more gate delays than a normal FMAC aligner/normalizer, and of
course fully pipelineable. :-)

Terje

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

Re: VVM question

<ce4181ec-d0cf-4a65-8ca9-d8e40d850f1fn@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1304:b0:35c:b77b:73b6 with SMTP id v4-20020a05622a130400b0035cb77b73b6mr9280540qtk.498.1664586955875;
Fri, 30 Sep 2022 18:15:55 -0700 (PDT)
X-Received: by 2002:aca:5808:0:b0:350:9790:7fe with SMTP id
m8-20020aca5808000000b00350979007femr379015oib.79.1664586955340; Fri, 30 Sep
2022 18:15:55 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Fri, 30 Sep 2022 18:15:55 -0700 (PDT)
In-Reply-To: <sg27qb$2lv$1@gioia.aioe.org>
Injection-Info: google-groups.googlegroups.com; posting-host=92.40.178.238; posting-account=soFpvwoAAADIBXOYOBcm_mixNPAaxW9p
NNTP-Posting-Host: 92.40.178.238
References: <sftuaa$but$1@newsreader4.netcologne.de> <5fd4c976-d72c-46f3-9fb4-584e72b628a2n@googlegroups.com>
<sfvckb$bok$2@newsreader4.netcologne.de> <sg0ctf$qoj$1@dont-email.me>
<2021Aug23.172406@mips.complang.tuwien.ac.at> <sg27qb$2lv$1@gioia.aioe.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <ce4181ec-d0cf-4a65-8ca9-d8e40d850f1fn@googlegroups.com>
Subject: Re: VVM question
From: luke.lei...@gmail.com (luke.l...@gmail.com)
Injection-Date: Sat, 01 Oct 2022 01:15:55 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 4259
 by: luke.l...@gmail.com - Sat, 1 Oct 2022 01:15 UTC

On Tuesday, August 24, 2021 at 8:41:02 AM UTC+1, Terje Mathisen wrote:
> Anton Ertl wrote:
> > Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> >> On 8/22/2021 10:44 PM, Thomas Koenig wrote:
> > |int m2(int * const restrict a, int n)
> > |{
> > | int m, nm;
> > | int i;
> > |
> > | m = INT_MIN;
> > | nm = -1;
> > | for (i=0; i<n; i++)
> > | {
> > | if (a[i] > m)
> > | {
> > | m = a[i];
> > | nm = i;
> > | }
> > | }
> > | return nm;
> > |}

going back to the original

> Modifying it to while (i+1<n && a[i] <= m) would work I think, but it is
> easier to check the index below:
> while (i<n) {
> while (i<n && a[i]<=m)
> i++;
> if (i < n) {
> m = a[i];
> nm = i;
> }
> i++;

it turns out this one is remarkably simple: use the characteristics
of mapreduce mode to overwrite nm from a parallel
comparison, it is not strictly necessary to perform the
additional skipping (while (i<n && a[i]<=m) i++)

SVP64 mapreduce mode is a misnomer, it actually simply
allows scalar results to continue to be written to during
looping, where normally the first scalar result written causes
early-termination of the horizontal vector loop.

> int m2(int * const restrict a, int n)
> {
> int m, nm;
> int i;
>
> m = INT_MIN;
> nm = -1;

first prepare offsets

setvl vl=16
sv.svstep *offs, srcstep # creates sequence 0 1 2 .. vl-1
li r8, 8 # use this with madd later

and nm-potential

li nm, -1
li nmbase, 0

next use CTR mode

> for (i=0; i<n; i++)
> {

setvl r1,0,16,0,1,1 # VL=r1=MIN(MAXVL,CTR)

perform the load of the vector data, elstrided:

sv.ld/els *a, 8(a_ptr)

> if (a[i] > m)
> {

comparison:

sv.cmp cr0.gt, *a, m

next, these two both use mapreduce mode with predication

> m = a[i];

sv.ori/mr/m=gt m,*a,0

> nm = i;

add-overwriting base with vector-offset into nm

sv.add/mr/m=gt nm, nmbase, *offs

> }

nmbase must be incremented by vl

add nmbase, nmbase, r1 # r1 contains copy of vl

TODO also remember to update ptr to a by 8*VL

madd a_ptr, r8, r1, a_ptr

branch and subtract VL from CTR if not end of loop

sv.bc/all 16, *0, loop

> }
> return nm;

mr r3, nmbase
blr

the trick here is the multiple overwrites of nm and m, even though
they are scalar, the usual "termination of looping because scalar result"
is switched *off* in mapreduce mode.
thus due to the vector predication the last successful conditional overwrite
"wins"

the second trick was to use a base nm which increments by VL, from a
vector of sequential constants.

there will be better/other methods, using data-dependent failfirst
will stop at the first compare-fail but will need "continuation"
(2 nested loops) whereas the mapreduce one is really simple but
relies on WaW hazards to be eliminated

Pages:1234
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor