Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

Always draw your curves, then plot your reading.


computers / alt.sys.pdp10 / how, technically, did the memory cache for the KL work?

SubjectAuthor
* how, technically, did the memory cache for the KL work?fishtoprecords
+- Re: how, technically, did the memory cache for the KL work?Lars Brinkhoff
`- Re: how, technically, did the memory cache for the KL work?Johnny Billquist

1
how, technically, did the memory cache for the KL work?

<2fd86437-7db3-4fb1-a7f6-2fbdb4e87481n@googlegroups.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=738&group=alt.sys.pdp10#738

 copy link   Newsgroups: alt.sys.pdp10
X-Received: by 2002:a05:622a:1b01:b0:343:582f:3e07 with SMTP id bb1-20020a05622a1b0100b00343582f3e07mr23589159qtb.578.1660765355813;
Wed, 17 Aug 2022 12:42:35 -0700 (PDT)
X-Received: by 2002:a05:6870:d154:b0:11c:4daf:d609 with SMTP id
f20-20020a056870d15400b0011c4dafd609mr2210317oac.85.1660765355548; Wed, 17
Aug 2022 12:42:35 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.sys.pdp10
Date: Wed, 17 Aug 2022 12:42:35 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=173.49.90.24; posting-account=5pAuXwkAAADYxu_vHG_N6x8Gdf1I-9kI
NNTP-Posting-Host: 173.49.90.24
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <2fd86437-7db3-4fb1-a7f6-2fbdb4e87481n@googlegroups.com>
Subject: how, technically, did the memory cache for the KL work?
From: pat22...@gmail.com (fishtoprecords)
Injection-Date: Wed, 17 Aug 2022 19:42:35 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 1699
 by: fishtoprecords - Wed, 17 Aug 2022 19:42 UTC

We started with a single 2040 with core memory. Over time, it got a lot more memory (eventually semiconductor) and the cache upgrade to a 2060.
We eventually ended up with a mix of 2060 and 2065 models.

Are there white papers or technical documentation of how it worked?

I know the basics, once the instruction being executed has calculated E, the effective address, some circuit looks up the upper bits of E in the cache.
If it finds a four word block that matches the address, the four words are sent to the memory controller. If not found, it then fetches the four word block from real memory.

My question is how is this logic executed?
How is the addresses searched?
etc. ?

Re: how, technically, did the memory cache for the KL work?

<7wedxeks4z.fsf@junk.nocrew.org>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=739&group=alt.sys.pdp10#739

 copy link   Newsgroups: alt.sys.pdp10
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!dotsrc.org!filter.dotsrc.org!news.dotsrc.org!not-for-mail
From: lars.s...@nocrew.org (Lars Brinkhoff)
Newsgroups: alt.sys.pdp10
Subject: Re: how, technically, did the memory cache for the KL work?
Organization: nocrew
References: <2fd86437-7db3-4fb1-a7f6-2fbdb4e87481n@googlegroups.com>
Date: Thu, 18 Aug 2022 06:00:44 +0000
Message-ID: <7wedxeks4z.fsf@junk.nocrew.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Cancel-Lock: sha1:6lh4TyufLI2gTw5LTYfJU+kCFWs=
MIME-Version: 1.0
Content-Type: text/plain
Lines: 6
NNTP-Posting-Host: f9dacf38.news.sunsite.dk
X-Trace: 1660802444 news.sunsite.dk 693 lars@junk.nocrew.org/51.15.56.219:49356
X-Complaints-To: staff@sunsite.dk
 by: Lars Brinkhoff - Thu, 18 Aug 2022 06:00 UTC

fishtoprecords wrote:
> Are there white papers or technical documentation of how it worked?

Maybe this, or something in its vicinity:

http://bitsavers.org/pdf/dec/pdp10/KL10/EK-MBOX-UD-004_May77.pdf

Re: how, technically, did the memory cache for the KL work?

<tdm3gi$1fk$1@news.misty.com>

 copy mid

https://www.novabbs.com/computers/article-flat.php?id=740&group=alt.sys.pdp10#740

 copy link   Newsgroups: alt.sys.pdp10
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!.POSTED.h77-53-236-14.cust.a3fiber.se!not-for-mail
From: bqt...@softjar.se (Johnny Billquist)
Newsgroups: alt.sys.pdp10
Subject: Re: how, technically, did the memory cache for the KL work?
Date: Thu, 18 Aug 2022 21:21:54 +0200
Organization: MGT Consulting
Message-ID: <tdm3gi$1fk$1@news.misty.com>
References: <2fd86437-7db3-4fb1-a7f6-2fbdb4e87481n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 18 Aug 2022 19:21:54 -0000 (UTC)
Injection-Info: news.misty.com; posting-host="h77-53-236-14.cust.a3fiber.se:77.53.236.14";
logging-data="1524"; mail-complaints-to="abuse@misty.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.12.0
Content-Language: en-US
In-Reply-To: <2fd86437-7db3-4fb1-a7f6-2fbdb4e87481n@googlegroups.com>
 by: Johnny Billquist - Thu, 18 Aug 2022 19:21 UTC

On 2022-08-17 21:42, fishtoprecords wrote:
> We started with a single 2040 with core memory. Over time, it got a lot more memory (eventually semiconductor) and the cache upgrade to a 2060.
> We eventually ended up with a mix of 2060 and 2065 models.
>
> Are there white papers or technical documentation of how it worked?
>
> I know the basics, once the instruction being executed has calculated E, the effective address, some circuit looks up the upper bits of E in the cache.
> If it finds a four word block that matches the address, the four words are sent to the memory controller. If not found, it then fetches the four word block from real memory.
>
> My question is how is this logic executed?
> How is the addresses searched?
> etc. ?

Not sure, but this seems to be a more generic question on how caches are
done?

In general, cached data are not stored in arbitrary locations in the
cache. Instead the address requested gets mapped to one, or a few cache
locations. And a comparison is then only done for the tag on those
locations to see if it actually is the correct data that sits there.

A very simple model would just do like this:
Let's assume the cache is 2K. Any memory location uses the 11 low bits
as the mapping to the cache location. Which means that every address at
a 2K interval maps to the same cache location. If we then have 18 total
address bits, then the high 7 bits are stored in the tag for that cache
location, in addition to the 36 data bits. When a read is executed, you
take the 11 low bits to find which cache location to check, and then you
compare the 7 high bits to the tag for that location. If it matches,
then you give the 36 bits of data from the cache, otherwise you read
from memory. Of course a write or a read from memory will also update
the cache the the new tag and data.

This would be called a direct cache. You can also have a n-way
associative cache, where you'd do the same as above, but you have n
locations for that 11 bit address location. On a read, the hardware
would compare to the tags of all n locations in parallel, and if you get
a hit on either, then that's the data you want. And then you need to
have some replacement algorithm to decide which cache entry to replace
if data is written or read from main memory, since you obviously don't
need to invalidate both entries that translate to the same location.

Some use round robin, other LRU.

If you were to store the data in arbitrary locations in the cache, then
the tag would need to be the full address, and then you'd want the cache
memory to be a CAM memory, which is addressed by content. So you'd
basically search it based on the tag (address), and if you have a hit,
you can return the data associated with that location. However, CAM
memories are rather expensive and power hungry. They (obviously) do
parallel lookups on all memory locations so that it happens in constant
time.

Page table caches are more common to have as CAM memories, since they
are usually much smaller, and you want to have less issues about
multiple contents competing for the same location in the cache.

Johnny

1
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor