linux-kernel - Re: Driver for tightly coupled memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <32819.1221629978@turing-police.cc.vt.edu>
Date:	Wed, 17 Sep 2008 01:39:38 -0400
From:	Valdis.Kletnieks@...edu
To:	Alessio Sangalli <alesan@...oweb.com>
Cc:	Ben Nizette <bn@...sdigital.com>, Ben Dooks <ben-linux@...ff.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Driver for tightly coupled memory

On Tue, 16 Sep 2008 22:27:41 PDT, Alessio Sangalli said:

> Well I should ask the details to the hardware engineers but it's like a
> separate channel than the one used for main memory. It is not cacheable
> either. To the CPU, it just appears to be mapped at some location on the
> addressable space. Accessing this TCM will not have any impact on main
> memory access, so bursts etc won't be interrupted; other than that, TCM
> has double the bandwidth than standard memory - but it's tiny in size,
> something like 8 to 32kB as I mentioned earlier.

Ah.  So it's basically just super-fast memory that can be accessed without
going through the usual memory bus.  Sounds like the cycle of reincarnation
strikes again - 30ish years ago, the DEC PDP10/20 processors implemented the
first few locations of memory in fast (for the time) chips, and then mapped
the general purpose registers onto it.  A favorite trick would be to copy a
small loop into locations 0-7 and then branch to it - basically executing
from the general registers.  The *real* fun started when people started doing
self-modifying code by doing arithmetic/logical operations on registers. ;)

Would it be more of a performance win to use the 8-32K to store speed-critical
code rather than a FIFO?  Just another idea for what to use it for, but that
would likely require a different API...

Content of type "application/pgp-signature" skipped