porting.texi

测试手写程序

@noindent
There are two parts of this that you might choose to alter. The first,
and most important, is the line involving @code{__libc_attr}.  That is
IRIX system-dependent code that gets the base of the table mapping
character codes to attributes.  You need to substitute code that obtains
the address of this table on your system.  If you want to use your
operating system's tables to map upper-case letters to lower-case, and
vice versa, you should initialize @code{_M_toupper} and
@code{_M_tolower} with those tables, in similar fashion.

Now, you have to write two functions to convert from upper-case to
lower-case, and vice versa.  Here are the IRIX versions:

@example
char
ctype<char>::do_toupper(char __c) const
@{ return _toupper(__c); @}

char
ctype<char>::do_tolower(char __c) const
@{ return _tolower(__c); @}
@end example

@noindent
Your C library provides equivalents to IRIX's @code{_toupper} and
@code{_tolower}.  If you initialized @code{_M_toupper} and
@code{_M_tolower} above, then you could use those tables instead.

Finally, you have to provide two utility functions that convert strings
of characters.  The versions provided here will always work -- but you
could use specialized routines for greater performance if you have
machinery to do that on your system:

@example
const char*
ctype<char>::do_toupper(char* __low, const char* __high) const
@{
  while (__low < __high)
    @{
      *__low = do_toupper(*__low);
      ++__low;
    @}
  return __high;
@}

const char* 
ctype<char>::do_tolower(char* __low, const char* __high) const
@{
  while (__low < __high)
    @{
      *__low = do_tolower(*__low);
      ++__low;
    @}
  return __high;
@}
@end example

You must also provide the @file{bits/ctype_inline.h} file, which
contains a few more functions.  On most systems, you can just copy
@file{config/os/generic/ctype_inline.h} and use it on your system.

In detail, the functions provided test characters for particular
properties; they are analogous to the functions like @code{isalpha} and
@code{islower} provided by the C library.

The first function is implemented like this on IRIX:

@example
bool
ctype<char>::
is(mask __m, char __c) const throw()
@{ return (_M_table)[(unsigned char)(__c)] & __m; @}
@end example

@noindent
The @code{_M_table} is the table passed in above, in the constructor.
This is the table that contains the bitmasks for each character.  The
implementation here should work on all systems.

The next function is:

@example
const char*
ctype<char>::
is(const char* __low, const char* __high, mask* __vec) const throw()
@{
  while (__low < __high)
    *__vec++ = (_M_table)[(unsigned char)(*__low++)];
  return __high;
@}
@end example

@noindent
This function is similar; it copies the masks for all the characters
from @code{__low} up until @code{__high} into the vector given by
@code{__vec}.

The last two functions again are entirely generic:

@example
const char*
ctype<char>::
scan_is(mask __m, const char* __low, const char* __high) const throw()
@{
  while (__low < __high && !this->is(__m, *__low))
    ++__low;
  return __low;
@}

const char*
ctype<char>::
scan_not(mask __m, const char* __low, const char* __high) const throw()
@{
  while (__low < __high && this->is(__m, *__low))
    ++__low;
  return __low;
@}
@end example

@c ---------------------------------------------------------------------
@c Thread safety
@c ---------------------------------------------------------------------

@node Thread safety
@chapter Thread safety

The C++ library string functionality requires a couple of atomic
operations to provide thread-safety.  If you don't take any special
action, the library will use stub versions of these functions that are
not thread-safe.  They will work fine, unless your applications are
multi-threaded.

If you want to provide custom, safe, versions of these functions, there
are two distinct approaches.  One is to provide a version for your CPU,
using assembly language constructs.  The other is to use the
thread-safety primitives in your operating system.  In either case, you
make a file called @file{bits/atomicity.h}.  

If you are using the assembly-language approach, put this code in
@file{config/cpu/<chip>/bits/atomicity.h}, where chip is the name of
your processor.  In that case, edit the switch statement in
@file{configure.target} to set the @code{cpu_include_dir}.  In either
case, set the switch statement that sets @code{ATOMICITYH} to be the
directory containing @file{bits/atomicity.h}.

With those bits out of the way, you have to actually write
@file{bits/atomicity.h} itself.  This file should be wrapped in an
include guard named @code{_BITS_ATOMICITY_H}.  It should define one
type, and two functions.  

The type is @code{_Atomic_word}.  Here is the version used on IRIX:

@example
typedef long _Atomic_word;
@end example

@noindent
This type must be a signed integral type supporting atomic operations.
If you're using the OS approach, use the same type used by your system's
primitives.  Otherwise, use the type for which your CPU provides atomic
primitives.

Then, you must provide two functions.  The bodies of these functions
must be equivalent to those provided here, but using atomic operations:

@example
static inline _Atomic_word
__attribute__ ((__unused__))
__exchange_and_add (_Atomic_word* __mem, int __val)
@{
  _Atomic_word __result = *__mem;
  *__mem += __val;
  return __result;
@}

static inline void
__attribute__ ((__unused__))
__atomic_add (_Atomic_word* __mem, int __val)
@{
  *__mem += __val;
@}
@end example

@c ---------------------------------------------------------------------
@c Numeric limits
@c ---------------------------------------------------------------------

@node Numeric limits
@chapter Numeric limits

The C++ library requires information about the fundamental data types,
such as the minimum and maximum representable values of each type.
You can define each of these values individually, but it is usually
easiest just to indicate how many bits are used in each of the data
types and let the library do the rest.  For information about the
macros to define, see the top of @file{include/bits/std_limits.h}.

If you need to define any macros, you can do so in
@file{os_defines.h}.  However, if all operating systems for your CPU
are likely to use the same values, you can provide a CPU-specific file
instead so that you do not have to provide the same definitions for
each operating system.  To take that approach, create a new file
called @file{limits.h} in your CPU configuration directory (e.g.,
@file{config/cpu/i386/bits}) and then modify @file{configure.target}
so that @code{LIMITSH} is set to the CPU directory (e.g.,
@file{config/cpu/i386}).  Note that @code{LIMITSH} should not include
the @samp{bits} part of the directory name.

@c ---------------------------------------------------------------------
@c Libtool
@c ---------------------------------------------------------------------

@node Libtool
@chapter Libtool

The C++ library is compiled, archived and linked with libtool.
Explaining the full workings of libtool is beyond the scope of this
document, but there are a few, particular bits that are necessary for
porting.

Some parts of the libstdc++-v3 library are compiled with the libtool
@code{--tags CXX} option (the C++ definitions for libtool).  Therefore,
@file{ltcf-cxx.sh} in the top-level directory needs to have the correct
logic to compile and archive objects equivalent to the C version of libtool,
@file{ltcf-c.sh}.  Some libtool targets have definitions for C but not
for C++, or C++ definitions which have not been kept up to date.

The C++ run-time library contains initialization code that needs to be
run as the library is loaded.  Often, that requires linking in special
object files when the C++ library is built as a shared library, or
taking other system-specific actions.

The libstdc++-v3 library is linked with the C version of libtool, even though it
is a C++ library.  Therefore, the C version of libtool needs to ensure
that the run-time library initializers are run.  The usual way to do
this is to build the library using @code{gcc -shared}.

If you need to change how the library is linked, look at
@file{ltcf-c.sh} in the top-level directory.  Find the switch statement
that sets @code{archive_cmds}.  Here, adjust the setting for your
operating system.

@c ---------------------------------------------------------------------
@c GFDL
@c ---------------------------------------------------------------------

@include fdl.texi

@c ---------------------------------------------------------------------
@c Epilogue
@c ---------------------------------------------------------------------

@contents
@bye