home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.arch      Apparently more than just beeps & boops      131,241 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 130,436 of 131,241   
   Chris M. Thomasson to MitchAlsup   
   Re: Memory ordering (Re: Multi-precision   
   05 Dec 25 14:55:36   
   
   From: chris.m.thomasson.1@gmail.com   
      
   On 12/5/2025 12:54 PM, 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.   
   >   
   > Compare Double, Swap Double::   
   >   
   > BOOLEAN DCAS( type oldp, type_t oldq,   
   >                type *p,   type_t *q,   
   >                type newp, type newq )   
   > {   
   >       type t = esmLOCKload( *p );   
   >       type r = esmLOCKload( *q );   
   >       if( t == oldp && r == oldq )   
   >       {   
   >                          *p = newp;   
   >            esmLOCKstore( *q,  newq );   
   >            return TRUE;   
   >       }   
   >       return FALSE;   
   > }   
   >   
   > Move Element from one place to another:   
   >   
   > BOOLEAN MoveElement( Element *fr, Element *to )   
   > {   
   >       Element *fn = esmLOCKload( fr->next );   
   >       Element *fp = esmLOCKload( fr->prev );   
   >       Element *tn = esmLOCKload( to->next );   
   >       esmLOCKprefetch( fn );   
   >       esmLOCKprefetch( fp );   
   >       esmLOCKprefetch( tn );   
   >       if( !esmINTERFERENCE() )   
   >       {   
   >                     fp->next = fn;   
   >                     fn->prev = fp;   
   >                     to->next = fr;   
   >                     tn->prev = fr;   
   >                     fr->prev = to;   
   >       esmLOCKstore( fr->next,  tn );   
   >                     return TRUE;   
   >       }   
   >       return FALSE;   
   > }   
   >   
   > So, I guess, you are not talking about what My 66000 cannot do, but   
   > only what other ISAs cannot do.   
      
   Any issues with live lock in here?   
      
   [...]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca