Re: mutex in frame code

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <r2r9sjas6h.fsf@happy.cygnus.com>you write:
  > Looking at the code one can see that the lock is used to insert into a
  > single-linked list.  This can be done safely without locks with an
  > compare & exchange instruction:
  > 
  > 	do
  > 	  {
  > 	    struct object *last = objects;
  > 	    ob->next = objects;
  > 	  }
  > 	while (compxchg (ob, last, ob) != 0);
  > 
  > with an appropriate compxchg function.  This function would be very
  > system-specific so Jason proposed to have a __builtin_cmpxchg function
  > and put the system specific bits into the .md files.
I think you want two primitives:

initialize a spin lock
spin until you get the lock


  > Now there is the problem that not all processors have such an opcode.
  > This is where the problems start.  E.g., the i386 processor has no
  > such opcode while i486 and up do.  I think this is the situation for
  > some other processor families as well.  Using the opcode nevertheless
  > would mean that there is not anymore full backward compatibility.
  > I.e., a gcc compiled for i486 will not work on i386 anymore.  I don't
  > think this is a problem personally.  We already have similar
  > restrictions (i686 code cannot be used on earlier processors) and i386
  > are also not anymore the commonly found platform.
This is a problem.

While i686 code can not be used on older processors, we do not generate i686
code by default.  ie, for the x86 we generate "common" code which can execute
on any variant of the chip.  To enable i686 specific features one has to use
a flag.


jeff