Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Going the speed of light is bad for your age.


devel / comp.arch / Re: Built-in queues

SubjectAuthor
* Re: Built-in queuesPaul A. Clayton
`* Re: Built-in queuesrobf...@gmail.com
 `* Re: Built-in queuesMitchAlsup
  `* Re: Built-in queuesStefan Monnier
   `- Re: Built-in queuesIvan Godard

1
Re: Built-in queues

<b13ad62b-3f8f-4950-8927-1c9cd4d11a43n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:57c4:: with SMTP id y4mr114654qvx.12.1623689531312;
Mon, 14 Jun 2021 09:52:11 -0700 (PDT)
X-Received: by 2002:a05:6808:14c8:: with SMTP id f8mr4245422oiw.7.1623689531083;
Mon, 14 Jun 2021 09:52:11 -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: Mon, 14 Jun 2021 09:52:10 -0700 (PDT)
In-Reply-To: <92023065-e481-471b-af02-0c378daea5acn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=64.26.99.248; posting-account=6JNn0QoAAAD-Scrkl0ClrfutZTkrOS9S
NNTP-Posting-Host: 64.26.99.248
References: <92023065-e481-471b-af02-0c378daea5acn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <b13ad62b-3f8f-4950-8927-1c9cd4d11a43n@googlegroups.com>
Subject: Re: Built-in queues
From: paaroncl...@gmail.com (Paul A. Clayton)
Injection-Date: Mon, 14 Jun 2021 16:52:11 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 22
 by: Paul A. Clayton - Mon, 14 Jun 2021 16:52 UTC

On Sunday, June 13, 2021 at 9:28:26 PM UTC-4, robf...@gmail.com wrote:
> The ANY1 ISA has support for built-in hardware queues accessible at high-speed (single cycle).
> These queues are not part of the main memory system and not subject to virtual memory. They
> have dedicated instructions for access. Queue instructions are PEEKQ, POPQ, PUSHQ, and
> STATQ. Not having seen other machines doing this makes me think it is a bad idea, but I do
> not see why at the moment. Currently the instruction trace queue is accessible.

MIPS Multi-Threading Application Specific Extension mentions a similar feature called
InterThread Communication Storage. A 64-bit cell can implement a FIFO.

The MT Principles of Operation does not provide much detail on expected uses,
but the feature's optional nature does imply that it was not expected to be
universally useful.

I seem to recall one of the Chinese extended MIPS implementations for HPC
included full/empty bits for a range of memory. With proper squinting this could
be viewed as a single-entry buffer FIFO. (Extending such to a more general FIFO
seems straightforward by allowing writes when 'full' with the value retained in
global write order.)

The concept of 'mailboxes' has appeared from time to time. (One might consider
full/empty bits for multithreaded communication comparable to ready bits for
dataflow processors.)

Re: Built-in queues

<90fdd956-7392-491f-83d0-16f086e72183n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:4447:: with SMTP id l7mr379818qvt.36.1623693669642; Mon, 14 Jun 2021 11:01:09 -0700 (PDT)
X-Received: by 2002:a9d:82b:: with SMTP id 40mr14523228oty.81.1623693669409; Mon, 14 Jun 2021 11:01:09 -0700 (PDT)
Path: i2pn2.org!i2pn.org!paganini.bofh.team!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!tr2.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, 14 Jun 2021 11:01:09 -0700 (PDT)
In-Reply-To: <b13ad62b-3f8f-4950-8927-1c9cd4d11a43n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2607:fea8:1de1:d400:507e:4d65:7ac4:bc09; posting-account=QId4bgoAAABV4s50talpu-qMcPp519Eb
NNTP-Posting-Host: 2607:fea8:1de1:d400:507e:4d65:7ac4:bc09
References: <92023065-e481-471b-af02-0c378daea5acn@googlegroups.com> <b13ad62b-3f8f-4950-8927-1c9cd4d11a43n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <90fdd956-7392-491f-83d0-16f086e72183n@googlegroups.com>
Subject: Re: Built-in queues
From: robfi...@gmail.com (robf...@gmail.com)
Injection-Date: Mon, 14 Jun 2021 18:01:09 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 15
 by: robf...@gmail.com - Mon, 14 Jun 2021 18:01 UTC

On Monday, June 14, 2021 at 12:52:12 PM UTC-4, Paul A. Clayton wrote:
>My 66000 gets up to 8 cache lines to participate in an ATOMIC event; so you get up to 64 double words
>that can change state instantaneously as seen by outside observers.

It looks like a bit of trickery in the semantics !esmInterference() must be setting a bus lock signal doing the actual lock. And esmLock() is just recording addresses.

I have been following along the My 66000 being suitably impressed. Can I get my hands on the docs for the My 66000?

It occurs to me that small stacks might be a lot more useful than fifos, but the same instructions could be used to access/implement both. A stack could be used in an interrupt routine to stack return addresses. There are also algorithms that make use of data stacks.

Re: Built-in queues

<774c4f70-ca6d-4db1-ade4-996cfce34be5n@googlegroups.com>

 copy mid

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

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:e4d:: with SMTP id 74mr17399238qko.6.1623694865031;
Mon, 14 Jun 2021 11:21:05 -0700 (PDT)
X-Received: by 2002:a9d:7f8f:: with SMTP id t15mr13159594otp.329.1623694864900;
Mon, 14 Jun 2021 11:21:04 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 14 Jun 2021 11:21:04 -0700 (PDT)
In-Reply-To: <90fdd956-7392-491f-83d0-16f086e72183n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:c61:3f99:736a:2902;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:c61:3f99:736a:2902
References: <92023065-e481-471b-af02-0c378daea5acn@googlegroups.com>
<b13ad62b-3f8f-4950-8927-1c9cd4d11a43n@googlegroups.com> <90fdd956-7392-491f-83d0-16f086e72183n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <774c4f70-ca6d-4db1-ade4-996cfce34be5n@googlegroups.com>
Subject: Re: Built-in queues
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Mon, 14 Jun 2021 18:21:05 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Mon, 14 Jun 2021 18:21 UTC

On Monday, June 14, 2021 at 1:01:10 PM UTC-5, robf...@gmail.com wrote:
> On Monday, June 14, 2021 at 12:52:12 PM UTC-4, Paul A. Clayton wrote:
> >My 66000 gets up to 8 cache lines to participate in an ATOMIC event; so you get up to 64 double words
> >that can change state instantaneously as seen by outside observers.
<
> It looks like a bit of trickery in the semantics !esmInterference() must be setting a bus lock signal doing the actual lock. And esmLock() is just recording addresses.
<
Nope, there is no "defined bus" and nothing to lock.
<
When an inbound memory reference (LD or PREfetch) with the lock bit set is decoded the lock
denotes that that memory reference is "participating" in an ATOMIC event. HW will monitor
the cache line for interference. There is a Branch-on-interference instruction in the ISA which
samples the HW interference and branches (or not) accordingly.
<
When an outbound memory reference (ST or PUSH) instruction is decoded, the lock bit tells
HW that the ATOMIC event has completed and to release the resources.
>
> I have been following along the My 66000 being suitably impressed. Can I get my hands on the docs for the My 66000?
<
All I need is an E-mail address. You can find mine.......
>
> It occurs to me that small stacks might be a lot more useful than fifos, but the same instructions could be used to access/implement both. A stack could be used in an interrupt routine to stack return addresses. There are also algorithms that make use of data stacks.
<
You have a choice, add instructions for the activities you want to support, and add and add and add
<
Or you can provide a means where SW can build all the desired mechanisms itself.
<
I chose the later; you get to make your own choice.

Re: Built-in queues

<jwvtum0qnlx.fsf-monnier+comp.arch@gnu.org>

 copy mid

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

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: monn...@iro.umontreal.ca (Stefan Monnier)
Newsgroups: comp.arch
Subject: Re: Built-in queues
Date: Mon, 14 Jun 2021 15:12:08 -0400
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <jwvtum0qnlx.fsf-monnier+comp.arch@gnu.org>
References: <92023065-e481-471b-af02-0c378daea5acn@googlegroups.com>
<b13ad62b-3f8f-4950-8927-1c9cd4d11a43n@googlegroups.com>
<90fdd956-7392-491f-83d0-16f086e72183n@googlegroups.com>
<774c4f70-ca6d-4db1-ade4-996cfce34be5n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org; posting-host="d5e7ea0a847fec74d4cd7b8139cedc52";
logging-data="4762"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KfppjzmOhctnL9s/haX91"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Cancel-Lock: sha1:nN1un8Pe69DN59Ew9Ebw0zbvDHY=
sha1:LLMo6cBuWmsVWXBKr/VGnGusC/g=
 by: Stefan Monnier - Mon, 14 Jun 2021 19:12 UTC

>> It occurs to me that small stacks might be a lot more useful than fifos,
>> but the same instructions could be used to access/implement both. A stack
>> could be used in an interrupt routine to stack return addresses. There are
>> also algorithms that make use of data stacks.
> You have a choice, add instructions for the activities you want to
> support, and add and add and add

I think ISA extensions in this area only make sense if there is a need
for more fine-grained communication than provided by shared memory.
So far, we seem to have lived just fine without them.

But maybe there is a case to be made when your CPU core is SMT and you
want to allow multiple threads to communicate directly within the
data-flow core of your OoO processor. It presupposes a very
fine-grained synchronization between the threads, e.g. in a function
that first spawns a new thread and then has the subsequent two threads
work each in its own loop, in "more or less lockstep"
a producer/consumer way. I can imagine situations where it could be
efficient, but most of them can be handled fairly efficiently some other
way (e.g. by merging the two loops, or by using a memory buffer between
the two).

I suspect it introduces more problems (like rolling back multiple
threads upon mispredictions]) than it's worth.

Stefan

Re: Built-in queues

<sa8esk$k2g$1@dont-email.me>

 copy mid

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

 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: Built-in queues
Date: Mon, 14 Jun 2021 13:40:53 -0700
Organization: A noiseless patient Spider
Lines: 32
Message-ID: <sa8esk$k2g$1@dont-email.me>
References: <92023065-e481-471b-af02-0c378daea5acn@googlegroups.com>
<b13ad62b-3f8f-4950-8927-1c9cd4d11a43n@googlegroups.com>
<90fdd956-7392-491f-83d0-16f086e72183n@googlegroups.com>
<774c4f70-ca6d-4db1-ade4-996cfce34be5n@googlegroups.com>
<jwvtum0qnlx.fsf-monnier+comp.arch@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 14 Jun 2021 20:40:52 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8502820e329019d05f984e551f3a33dd";
logging-data="20560"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19EWtx3cCP3ncAYHCp7+0EF"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
Cancel-Lock: sha1:2SNj4hb2TFKwVYtHOyfqALDFEpU=
In-Reply-To: <jwvtum0qnlx.fsf-monnier+comp.arch@gnu.org>
Content-Language: en-US
 by: Ivan Godard - Mon, 14 Jun 2021 20:40 UTC

On 6/14/2021 12:12 PM, Stefan Monnier wrote:
>>> It occurs to me that small stacks might be a lot more useful than fifos,
>>> but the same instructions could be used to access/implement both. A stack
>>> could be used in an interrupt routine to stack return addresses. There are
>>> also algorithms that make use of data stacks.
>> You have a choice, add instructions for the activities you want to
>> support, and add and add and add
>
> I think ISA extensions in this area only make sense if there is a need
> for more fine-grained communication than provided by shared memory.
> So far, we seem to have lived just fine without them.
>
> But maybe there is a case to be made when your CPU core is SMT and you
> want to allow multiple threads to communicate directly within the
> data-flow core of your OoO processor. It presupposes a very
> fine-grained synchronization between the threads, e.g. in a function
> that first spawns a new thread and then has the subsequent two threads
> work each in its own loop, in "more or less lockstep"
> a producer/consumer way. I can imagine situations where it could be
> efficient, but most of them can be handled fairly efficiently some other
> way (e.g. by merging the two loops, or by using a memory buffer between
> the two).

Yes, but it doesn't have to be OOO and can be two different cores rather
than SMT in one.

> I suspect it introduces more problems (like rolling back multiple
> threads upon mispredictions]) than it's worth.

Maybe true with SMT; we don't SMT. Not a problem with separate cores.

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor