From: user5857@newsgrouper.org.invalid   
      
   scott@slp53.sl.home (Scott Lurndal) posted:   
      
   > ERROR "unexpected byte sequence starting at index 736: '\xC2'" while   
   decoding:   
   >   
   > MitchAlsup  writes:   
   > >   
   > >"Chris M. Thomasson"  posted:   
   > >   
   > >> On 12/6/2025 5:42 AM, David Brown wrote:   
   > >> > On 05/12/2025 21:54, MitchAlsup wrote:   
   > >> >>   
   > >> >> David Brown  posted:   
   > >> >>   
   > >> >>> On 05/12/2025 18:57, MitchAlsup wrote:   
   > >> >>>>   
   > >> >>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:   
   > >> >>>>   
   > >> >>>>> David Brown  writes:   
   > >> >>>>>> "volatile" /does/ provide guarantees - it just doesn't provide   
   enough   
   > >> >>>>>> guarantees for multi-threaded coding on multi-core systems.   
   > >> >>>>>> Basically,   
   > >> >>>>>> it only works at the C abstract machine level - it does nothing   
   that   
   > >> >>>>>> affects the hardware.  So volatile writes are ordered at the C   
   level,   
   > >> >>>>>> but that says nothing about how they might progress through storage   
   > >> >>>>>> queues, caches, inter-processor communication buses, or whatever.   
   > >> >>>>>   
   > >> >>>>> You describe in many words and not really to the point what can be   
   > >> >>>>> explained concisely as: "volatile says nothing about memory ordering   
   > >> >>>>> on hardware with weaker memory ordering than sequential   
   consistency".   
   > >> >>>>> If hardware guaranteed sequential consistency, volatile would   
   provide   
   > >> >>>>> guarantees that are as good on multi-core machines as on single-core   
   > >> >>>>> machines.   
   > >> >>>>>   
   > >> >>>>> However, for concurrent manipulations of data structures, one wants   
   > >> >>>>> atomic operations beyond load and store (even on single-core   
   systems),   
   > >> >>>>   
   > >> >>>> Such as ????   
   > >> >>>   
   > >> >>> Atomic increment, compare-and-swap, locks, loads and stores of sizes   
   > >> >>> bigger than the maximum load/store size of the processor.   
   > >> >>   
   > >> >> My 66000 ISA can::   
   > >> >>   
   > >> >> LDM/STM can LD/ST up to 32   DWs   as a single ATOMIC   
   instruction.   
   > >> >> MM      can MOV   up to 8192 bytes as a single   
   ATOMIC instruction.   
   > >> >>   
   > >> >   
   > >> > The functions below rely on more than that - to make the work, as far as   
   > >> > I can see, you need the first "esmLOCKload" to lock the bus and also   
   > >> > lock the core from any kind of interrupt or other pre-emption, lasting   
   > >> > until the esmLOCKstore instruction.  Or am I missing something here?   
   > >>   
   > >> Lock the BUS? Only when shit hits the fan. What about locking the cache   
   > >> line? Actually, I think we can "force" an x86/x64 to lock the bus if we   
   > >> do a LOCK'ed RMW on memory that straddles cache lines?   
   > >   
   > >In the My 66000 case, Mem References can lock up to 8 cache lines.   
   >   
   > What if two processors have intersecting (but not fully overlapping)   
   > sets of those 8 cache lines?   
   >   
   > Can you guarantee forward progress?   
      
   Yes.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)