Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Arguments for a sane ISA 6-years later
Date: Mon, 29 Jul 2024 13:20:44 -0500
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <v88mhu$jit2$1@dont-email.me>
References: <b5d4a172469485e9799de44f5f120c73@www.novabbs.org>
 <v7ubd4$2e8dr$1@dont-email.me> <v7uc71$2ec3f$1@dont-email.me>
 <2024Jul26.190007@mips.complang.tuwien.ac.at> <v872h5$alfu$2@dont-email.me>
 <579ed190735c42fbd995f1b0b403e123@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 29 Jul 2024 20:20:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c8aa09e2d45f8fb38190453b39c47ea3";
	logging-data="641954"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19pC5P3sm2chqOJ9CYFMOqQUuk6JYMcxbY="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9A1RWSFyFRs99v4s8qNZxWoiWq0=
In-Reply-To: <579ed190735c42fbd995f1b0b403e123@www.novabbs.org>
Content-Language: en-US
Bytes: 6744

On 7/29/2024 12:38 PM, MitchAlsup1 wrote:
> On Mon, 29 Jul 2024 3:32:52 +0000, Chris M. Thomasson wrote:
> 
>> On 7/26/2024 10:00 AM, Anton Ertl wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>> On 7/25/2024 1:09 PM, BGB wrote:
>>>>> At least with a weak model, software knows that if it doesn't go 
>>>>> through
>>>>> the rituals, the memory will be stale.
>>>
>>> There is no guarantee of staleness, only a lack of stronger ordering
>>> guarantees.
>>>
>>>> The weak model is ideal for me. I know how to program for it
>>>
>>> And the fact that this model is so hard to use that few others know
>>> how to program for it make it ideal for you.
>>>
>>>> and it's more efficient
>>>
>>> That depends on the hardware.
>>>
>>> Yes, the Alpha 21164 with its imprecise exceptions was "more
>>> efficient" than other hardware for a while, then the Pentium Pro came
>>> along and gave us precise exceptions and more efficiency.  And
>>> eventually the Alpha people learned the trick, too, and 21264 provided
>>> precise exceptions (although they did not admit this) and more
>>> efficieny.
>>>
>>> Similarly, I expect that hardware that is designed for good TSO or
>>> sequential consistency performance will run faster on code written for
>>> this model than code written for weakly consistent hardware will run
>>> on that hardware.  That's because software written for weakly
>>> consistent hardware often has to insert barriers or atomic operations
>>> just in case, and these operations are slow on hardware optimized for
>>> weak consistency.
>>>
>>> By contrast, one can design hardware for strong ordering such that the
>>> slowness occurs only in those cases when actual (not potential)
>>> communication between the cores happens, i.e., much less frequently.
>>>
>>>> and sometimes use cases do not care if they encounter "stale" data.
>>>
>>> Great.  Unless these "sometimes" cases are more often than the cases
>>> where you perform some atomic operation or barrier because of
>>> potential, but not actual communication between cores, the weak model
>>> is still slower than a well-implemented strong model.
>>
>> A strong model? You mean I don't have to use any memory barriers at all?
>> Tell that to SPARC in RMO mode... How strong? Even the x86 requires a
>> membar when a store followed by a load to another location shall be
>> respected wrt order. Store-Load. #StoreLoad over on SPARC. ;^)
> 
> DRAM does not need this property, MMI/O does.
> 

As I see it, it makes sense to treat MMIO separately from normal memory 
access:
   Memory may use a much weaker model;
   For MMIO, generally every access needs to be synchronous.


In most cases, for MMIO, it makes sense to pay this cost, even if it 
means that access is slower.

In my case though, some of the hardware uses DRAM-backed buffers, which 
makes more of a pain for memory consistency.

But, then one has to make a tradeoff of whether it is better to use 
normal memory access and flushing, or No-Cache/Volatile access (which 
makes accesses consistent, but comes at a fairly steep performance penalty).


>> If you can force everything to be #StoreLoad (*) and make it faster than
>> a handcrafted algo on a very weak memory system, well, hats off! I
>> thought it was easier for a HW guy to implement weak consistency? At the
>> cost of the increased complexity wrt programming the sucker! ;^)
> 
> Or HW can have different order strengths based on where the PTE
> sends the request. DRAM gets causal order, ATOMICs to DRAM get
> sequential consistency, MMI/O gets sequential consistency,
> Configuration gets strong ordering.
> 
> Programmer has to do nothing.
> 

In my case, thus far it is based partly on the high 4 bits of the address:
   0..B: Virtual address, cached
   C, physical addressed, cached
   D, physical addressed, non-cached
   E, reserved
   F, MMIO, non-cached.

For virtual memory, the TLB can also encode the use of non-cached memory.

Considered, but still not implemented as of yet, would be memory 
operations that encode the use of non-cached access.

Most likely, this would be as a special case of the existing LDOP/OPST 
mechanism (was also used for the RV64 AMO operations).

The same mechanism would behave as LoadOp, OpStore, or AMO, depending on 
how it was used. Currently, these behave as normal access, but it might 
make sense to allow them to signal Volatile/NoCache.


There is a bit currently used in the encoding to signal Imm6 in BJX2, 
but no effect on the operation itself. It is possible this bit (in the 
operation) could be repurposed to signal Volatile access, but would need 
a way to signal it in the encoding.

Well, and/or make XCHG special:
Say, Load+XCHG is assumed Volatile, as is Store+XCHG, but in the latter 
case one ignores the result of the XCHG if the intention is merely to 
store something (and use a plain Load+Store sequence if one intends to 
perform a non-volatile exchange).

If other Volatile AMO operations may only be encoded in RISC-V Mode, 
this probably isn't a huge loss...

Well, and/or I drop the Imm6 case, which isn't really used much anyways.
But, could be used to encode things like "*(int *)ptr+=4;" as a single 
operation.


>>
>> (*) Not just #StoreLoad for full consistency, you would need :
>>
>> MEMBAR #StoreLoad | #LoadStore | #StoreStore | #LoadLoad
>>
>> right?