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,439 of 131,241   
   MitchAlsup to All   
   Re: Memory ordering (Re: Multi-precision   
   05 Dec 25 20:54:00   
   
   From: user5857@newsgrouper.org.invalid   
      
   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.   
      
   >                                                            Even with a   
   > single core system you can have pre-emptive multi-threading, or at least   
   > interrupt routines that may need to cooperate with other tasks on data.   
   >   
   > >   
   > >> and I don't think that C with just volatile gives you such guarantees.   
   > >>   
   > >> - anton   
   >   
      
   --- 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