Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
From: MitchAlsup <MitchAlsup@aol.com>
Newsgroups: comp.arch
Subject: Re: M68k add to memory is not a mistake any more
Date: Tue, 14 Feb 2012 09:38:27 -0800 (PST)
Organization: http://groups.google.com
Lines: 49
Message-ID: <25944214.14.1329241107725.JavaMail.geo-discussion-forums@ynel5>
References: <ggtgp-8D1AEA.03180231012012@netnews.mchsi.com> <14657004.930.1329107546746.JavaMail.geo-discussion-forums@ynbt34> <jhaice$q77$1@gosset.csi.cam.ac.uk> <31733283.1178.1329150998236.JavaMail.geo-discussion-forums@ynel11> <jhdavn$5qb$1@gosset.csi.cam.ac.uk>
NNTP-Posting-Host: 72.177.28.22
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1329241108 18993 127.0.0.1 (14 Feb 2012 17:38:28 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 14 Feb 2012 17:38:28 +0000 (UTC)
Cc: nmm1@cam.ac.uk
In-Reply-To: <jhdavn$5qb$1@gosset.csi.cam.ac.uk>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=72.177.28.22; posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
User-Agent: G2/1.0
X-Google-Web-Client: true
X-Received-Bytes: 3829
Xref: x330-a1.tempe.blueboxinc.net comp.arch:5934

On Tuesday, February 14, 2012 3:53:59 AM UTC-6, nm...@cam.ac.uk wrote:
> In article <31733283.1178.1329150998236.JavaMail.geo-discussion-forums@yn=
el11>,
> MitchAlsup  wrote:
> >
> >> Well, some of the memory consistency logic might need tweaking,
> >> but most of that should already have been done.  As Terje says,
> >> there isn't any problem in adding quite a lot of small, simple
> >> (in order?) cores.  The memory access of those could be filtered
> >> through a private cache, which would keep the impact on the
> >> memory system down.  And they don't really need any floating-point
> >> support, either.
> >
> >Of the machines that I am familiar, the busses that "get to" the SB chip=
s h=3D
> >ave the complete cache coherency protocol, its just that the vendor has =
cho=3D
> >sen not to document the protocol such that others can use it. Once the v=
end=3D
> >or puts a core (or more than one) on the SB chip the needs for that secr=
ecy=3D
> > vanish......
>=20
> That wasn't what I meant.  If you added (say) 20 very small cores
> to an 8 core system, each using the same cache interface, the amount
> of interconnect increases considerably.  If you make those 20 cores
> share a separate cache, you are increasing the size only from 8 to 9
> as the memory system sees it.  And very small cores that are usually
> waiting to service an interrupt shouldn't be a problem like that.

I am adding those tiny cores inside a chip that already has an appropriate =
buss running down to it. In the current embodiments, the SB chip is simply =
using the incoherent portion of the bus protocol, but the whole protocol is=
 available were the SB chip to start talking in a coherent manner. Thus, th=
e number of wires remains the same, the speeds remain the same, some of the=
 protocol useage changes.

Once the SB become <at least> partially coherent, it makes perfect sense to=
 provide a cache to speed up memory accesses for the same reasons it justif=
ies caches through out the CPU hierarchy to memory.

I suspect, though, that a single core, dedicated to only interrupt processi=
ng on that one SB chip, has plenty of cycles to deal with the typical deskt=
op PC interrupt rates. And since these cores are not waiting the 5 microsec=
onds for a response from a device register (because the device register is =
on the same chip as the core) the latency of processing the interrupt seen =
by the device will be lower, even with slower cores doing the work.

Mitch