OSDev.org

LoseThos wrote:Suppose you have two cores and a global memory variable which is cached. They both have accessed recently so each core has it in it's local cache. Core #0 changes it. Core #0 can write-back invalidate cache, writing everything out of cache. (Just pushing one value from cache to mem would be good, but WbInvd does the job.) Now, you have core #1... how do you fetch the updated value sitting in memory when you have a different value in your local cache?

For 80x86, if the value is in both CPU's caches then the cache line would be in the "shared" state. If the first CPU wants to modify the cache line, then it has to tell the other CPU/s to invalidate their copy of the cache line first (to get the cache line into the "exclusive" state), and after the first CPU has modified the cache line it would be set to the "modified" state in the first CPU. Now, if the other CPU wants to read that cache line again it'd look in it's cache and find nothing (as the cache line was invalidated) and it'd need to ask for the cache line again. The current copy of the cache line would be sent from the first CPU to the other CPU and the cache line would return to the "shared" state. You would not get a stale value from RAM.

Basically what I'm saying is that the hardware uses MESI cache states to ensure that all caches remain coherent, and an instruction that bypasses the MESI states and gets a value directly from RAM would usually get a wrong/stale value from RAM (instead of getting the right/current value from wherever it currently is).

Owen wrote:Ever tried implementing randomness from completely nonrandom components?

As for MD5, SHA and AES, theyre too complex to do with instructions. Better off with some kind of coprocessor which you tell to DMA over a region and do the work. CRC32 is simple enough you could possibly implement it in a CPU as an instruction you call for each byte (or word, or long)

LOCK just stops the other processors from taking the cache line in the middle of the instruction, nothing more.

int cnt1,cnt2,lock,done;

void CPU1Job()
{
  while (!done) {

    //Unlocked Btr
    while (!Btr(&lock,0) && !done);
    if (!done)
      cnt1++;
  }

  done=FALSE;

  while (!done) {

    //Locked Btr
    while (!LBtr(&lock,0) && !done);
    if (!done)
      cnt2++;
  }

  done=FALSE;

}

void CPU0Job()
{
  I8 i;

  done=FALSE;
  lock=0;
  cnt1=0;
  cnt2=0;
  WbInvd;

  MPJob(&CPU1Job); //Start job on CPU1

  for (i=0;i<100;i++) {
    Bts(&lock,0);
    Sleep(1);
  }
  done=TRUE;

  for (i=0;i<100;i++) {
    Bts(&lock,0);
    Sleep(1);
  }
  done=TRUE;

  PrintF("Count1:%d  Count2:%d\r\n",cnt1,cnt2);
}

LoseThos wrote:You know... they have locked prefixes on read-modify-write instructions and those bypass cache. Why can't they have a lock prefix for MOV that bypasses cache? (I don't care if it's separate opcodes)

LoseThos wrote:You have to admit my proposed instructions -- write straight to RAM and read straight from RAM would be handy, even if there are other way to do it. getting all cores to invalidate a location is not exactly convenient! I could use a locked XCHG instruction... but that puts a crazy value into the location which might create havoc.

Troy Martin wrote:Three words: LOCK CMPXCHG8B EAX

Owen wrote: As for the AES/etc, theyre very implementable in hardware. But theyre not sanely implementable as CPU instructions (Except for CRC32). AFAIK, Via's AES is on the chipset. In any case, encryption algorithms are better operating in parallel with the CPU else they'd end up being 10 cycle instructions or such