MT string, to do next

[Benjamin Kosnik]

> The 386 doesn't have a "lock" instruction, and will trap if it sees it.
> Our current config/cpu/i386/atomicity.h erroneously assumes that we are 
> compiling for a 486 or better.  As a result, libstdc++ string code will 
> fail on a 386 (and on my NexGen P110, too).  

No. The config script looks for:

      i486 | i586 | i686 | i786)
	cpu_include_dir="config/cpu/i386"
        ;;

Note that i386, the thing that you (Nathan) are so concerned with, uses:

      *)
	cpu_include_dir="config/cpu/generic"
        ;;


Thus, no traps. Since Uli has made this a non-issue anyway, it's not 
really important. I just thought I'd clarify...

The reality is that the solution adopted is far more flexible than the 
current v2 approach, (which consists of defines for x86 and 
sparc32/sparc64 in bastring) while adding more platforms (alpha, ppc). I 
think it's a win. And, I think this complicated dynamic linking stuff is 
not necessary. Ulrich is right, we can't cripple the c++ library for 
ancient hardware. 

The question I have is if this same approach for primitives can be used 
for IO-locking, or if a pthreads approach is required. See these URLs for 
the problem statement:

http://sourceware.cygnus.com/ml/libstdc++/2000-q1/msg00323.html
http://sourceware.cygnus.com/ml/libstdc++/2000-q1/msg00113.html
http://sourceware.cygnus.com/ml/libstdc++/1999-q2/msg00168.html
http://sourceware.cygnus.com/ml/libstdc++/1999-q2/msg00159.html

Obviously, including pthread.h is a no-no, when we have the config work 
done to select between thread types (ie, use c++threads.h and typedef 
pthread_mutext to mutext_type or something.) That is, if a thread library 
is the way to go here...


 -benjamin