Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Arguments for a sane ISA 6-years later
Date: Thu, 1 Aug 2024 20:06:10 +0000
Organization: Rocksolid Light
Message-ID: <55b647d46e79c54dc1261bbd037db3ac@www.novabbs.org>
References: <b5d4a172469485e9799de44f5f120c73@www.novabbs.org> <v7ubd4$2e8dr$1@dont-email.me> <v7uc71$2ec3f$1@dont-email.me> <2024Jul26.190007@mips.complang.tuwien.ac.at> <v811ub$309dk$1@dont-email.me> <2024Jul29.145933@mips.complang.tuwien.ac.at> <v88gru$ij11$1@dont-email.me> <2024Jul30.114424@mips.complang.tuwien.ac.at> <v8bi3e$16ahe$1@dont-email.me> <2024Aug1.191028@mips.complang.tuwien.ac.at> <gLPqO.1578$vu%c.859@fx08.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1136105"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$Icu.HFVWTmgmwWur6gFJaeEu.umNP3D/L9BAbAvi.zzb3txidEBb6
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 3495
Lines: 45

On Thu, 1 Aug 2024 17:39:24 +0000, Scott Lurndal wrote:

> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>BGB <cr88192@gmail.com> writes:
>>>Some amount of the cases where consistency issues have come up in my
>>>case have do do with RAM-backed hardware devices, like the rasterizer
>>>module. It has its own internal caches that need to be flushed, and not
>>>flushing caches (between this module and CPU) when trying to "transfer"
>>>control over things like the framebuffer or Z-buffer, can result in
>>>obvious graphical issues (and, texture-corruption doesn't necessarily
>>>look good either).
>>
>>The approach taken on AMD64 CPUs is to have different memory types
>>(and associated memory type range registers).  Plain DRAM is
>>write-back cached, but there is also write-through and uncacheable
>>memory.  For a frame buffer that is read by some hardware that can
>>access the memory independently, write-through seems to be the way to
>>go.
>
> In addition, ARM64 CPUs include allocation hints in
> the memory type such as 'read allocate', 'transient read allocate',
> 'write allocate' as well has having optionally multiple coherency
> domains (inner and outer sharable).

Sorry, I don't understand the word 'allocate' ?!?

In My 66000 I use the term allocate wrt cache lines as a line that
resides in the cache that may NOT have a defined DRAM address.
These lines can float around the cache hierarchy as desired.

BOOT uses the caches as main memory while it rummages through PCIe
looking for devices (and now memory), and while DRAM is discovered,
initialized, tuned, and made ready for general use. These lines
have PTEs with the 'Allocate' cache specifier.

The Call Stack uses Allocate cache lines which have the property
that if they are freed before they are written to DRAM, they can
be discarded instead of being written back. These cache lines
have a TPE with both the 'allocate' specifier, and RWE = 000 so
the application cannot LD or ST to these lines--only prologue
and epilogue instructions are allowed access, but these lines
do have an actual DRAM address.

...

So, what definition does ARM apply to 'allocate' ??