OpenCores
URL https://opencores.org/ocsvn/openrisc_me/openrisc_me/trunk

Subversion Repositories openrisc_me

[/] [openrisc/] [trunk/] [gnu-src/] [gcc-4.5.1/] [libstdc++-v3/] [doc/] [html/] [manual/] [internals.html] - Blame information for rev 424

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 424 jeremybenn 
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
2 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
3 
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Porting to New Hardware or Operating Systems</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><meta name="keywords" content="&#10;      ISO C++&#10;    , &#10;      internals&#10;    " /><meta name="keywords" content="&#10;      ISO C++&#10;    , &#10;      library&#10;    " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="prev" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="next" href="test.html" title="Test" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Porting to New Hardware or Operating Systems</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="appendix_porting.html">Prev</a> </td><th width="60%" align="center">Appendix B. 
4 
  Porting and Maintenance
5 
 
6 
</th><td width="20%" align="right"> <a accesskey="n" href="test.html">Next</a></td></tr></table><hr /></div><div class="sect1" title="Porting to New Hardware or Operating Systems"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.internals"></a>Porting to New Hardware or Operating Systems</h2></div></div></div><p>
7 
</p><p>This document explains how to port libstdc++ (the GNU C++ library) to
8 
a new target.
9 
</p><p>In order to make the GNU C++ library (libstdc++) work with a new
10 
target, you must edit some configuration files and provide some new
11 
header files.  Unless this is done, libstdc++ will use generic
12 
settings which may not be correct for your target; even if they are
13 
correct, they will likely be inefficient.
14 
   </p><p>Before you get started, make sure that you have a working C library on
15 
your target.  The C library need not precisely comply with any
16 
particular standard, but should generally conform to the requirements
17 
imposed by the ANSI/ISO standard.
18 
   </p><p>In addition, you should try to verify that the C++ compiler generally
19 
works.  It is difficult to test the C++ compiler without a working
20 
library, but you should at least try some minimal test cases.
21 
   </p><p>(Note that what we think of as a "target," the library refers to as
22 
a "host."  The comment at the top of <code class="code">configure.ac</code> explains why.)
23 
   </p><div class="sect2" title="Operating System"><div class="titlepage"><div><div><h3 class="title"><a id="internals.os"></a>Operating System</h3></div></div></div><p>If you are porting to a new operating system (as opposed to a new chip
24 
using an existing operating system), you will need to create a new
25 
directory in the <code class="code">config/os</code> hierarchy.  For example, the IRIX
26 
configuration files are all in <code class="code">config/os/irix</code>.  There is no set
27 
way to organize the OS configuration directory.  For example,
28 
<code class="code">config/os/solaris/solaris-2.6</code> and
29 
<code class="code">config/os/solaris/solaris-2.7</code> are used as configuration
30 
directories for these two versions of Solaris.  On the other hand, both
31 
Solaris 2.7 and Solaris 2.8 use the <code class="code">config/os/solaris/solaris-2.7</code>
32 
directory.  The important information is that there needs to be a
33 
directory under <code class="code">config/os</code> to store the files for your operating
34 
system.
35 
</p><p>You might have to change the <code class="code">configure.host</code> file to ensure that
36 
your new directory is activated.  Look for the switch statement that sets
37 
<code class="code">os_include_dir</code>, and add a pattern to handle your operating system
38 
if the default will not suffice.  The switch statement switches on only
39 
the OS portion of the standard target triplet; e.g., the <code class="code">solaris2.8</code>
40 
in <code class="code">sparc-sun-solaris2.8</code>.  If the new directory is named after the
41 
OS portion of the triplet (the default), then nothing needs to be changed.
42 
   </p><p>The first file to create in this directory, should be called
43 
<code class="code">os_defines.h</code>.  This file contains basic macro definitions
44 
that are required to allow the C++ library to work with your C library.
45 
   </p><p>Several libstdc++ source files unconditionally define the macro
46 
<code class="code">_POSIX_SOURCE</code>.  On many systems, defining this macro causes
47 
large portions of the C library header files to be eliminated
48 
at preprocessing time.  Therefore, you may have to <code class="code">#undef</code> this
49 
macro, or define other macros (like <code class="code">_LARGEFILE_SOURCE</code> or
50 
<code class="code">__EXTENSIONS__</code>).  You won't know what macros to define or
51 
undefine at this point; you'll have to try compiling the library and
52 
seeing what goes wrong.  If you see errors about calling functions
53 
that have not been declared, look in your C library headers to see if
54 
the functions are declared there, and then figure out what macros you
55 
need to define.  You will need to add them to the
56 
<code class="code">CPLUSPLUS_CPP_SPEC</code> macro in the GCC configuration file for your
57 
target.  It will not work to simply define these macros in
58 
<code class="code">os_defines.h</code>.
59 
   </p><p>At this time, there are a few libstdc++-specific macros which may be
60 
defined:
61 
   </p><p><code class="code">_GLIBCXX_USE_C99_CHECK</code> may be defined to 1 to check C99
62 
function declarations (which are not covered by specialization below)
63 
found in system headers against versions found in the library headers
64 
derived from the standard.
65 
   </p><p><code class="code">_GLIBCXX_USE_C99_DYNAMIC</code> may be defined to an expression that
66 
yields 0 if and only if the system headers are exposing proper support
67 
for C99 functions (which are not covered by specialization below).  If
68 
defined, it must be 0 while bootstrapping the compiler/rebuilding the
69 
library.
70 
   </p><p><code class="code">_GLIBCXX_USE_C99_LONG_LONG_CHECK</code> may be defined to 1 to check
71 
the set of C99 long long function declarations found in system headers
72 
against versions found in the library headers derived from the
73 
standard.
74 
 
75 
   </p><p><code class="code">_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC</code> may be defined to an
76 
expression that yields 0 if and only if the system headers are
77 
exposing proper support for the set of C99 long long functions.  If
78 
defined, it must be 0 while bootstrapping the compiler/rebuilding the
79 
library.
80 
   </p><p><code class="code">_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC</code> may be defined to an
81 
expression that yields 0 if and only if the system headers
82 
are exposing proper support for the related set of macros.  If defined,
83 
it must be 0 while bootstrapping the compiler/rebuilding the library.
84 
   </p><p><code class="code">_GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK</code> may be defined
85 
to 1 to check the related set of function declarations found in system
86 
headers against versions found in the library headers derived from
87 
the standard.
88 
   </p><p><code class="code">_GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC</code> may be defined
89 
to an expression that yields 0 if and only if the system headers
90 
are exposing proper support for the related set of functions.  If defined,
91 
it must be 0 while bootstrapping the compiler/rebuilding the library.
92 
   </p><p>Finally, you should bracket the entire file in an include-guard, like
93 
this:
94 
   </p><pre class="programlisting">
95 
 
96 
#ifndef _GLIBCXX_OS_DEFINES
97 
#define _GLIBCXX_OS_DEFINES
98 
...
99 
#endif
100 
</pre><p>We recommend copying an existing <code class="code">os_defines.h</code> to use as a
101 
starting point.
102 
   </p></div><div class="sect2" title="CPU"><div class="titlepage"><div><div><h3 class="title"><a id="internals.cpu"></a>CPU</h3></div></div></div><p>If you are porting to a new chip (as opposed to a new operating system
103 
running on an existing chip), you will need to create a new directory in the
104 
<code class="code">config/cpu</code> hierarchy.  Much like the <a class="link" href="internals.html#internals.os" title="Operating System">Operating system</a> setup,
105 
there are no strict rules on how to organize the CPU configuration
106 
directory, but careful naming choices will allow the configury to find your
107 
setup files without explicit help.
108 
</p><p>We recommend that for a target triplet <code class="code">&lt;CPU&gt;-&lt;vendor&gt;-&lt;OS&gt;</code>, you
109 
name your configuration directory <code class="code">config/cpu/&lt;CPU&gt;</code>.  If you do this,
110 
the configury will find the directory by itself.  Otherwise you will need to
111 
edit the <code class="code">configure.host</code> file and, in the switch statement that sets
112 
<code class="code">cpu_include_dir</code>, add a pattern to handle your chip.
113 
   </p><p>Note that some chip families share a single configuration directory, for
114 
example, <code class="code">alpha</code>, <code class="code">alphaev5</code>, and <code class="code">alphaev6</code> all use the
115 
<code class="code">config/cpu/alpha</code> directory, and there is an entry in the
116 
<code class="code">configure.host</code> switch statement to handle this.
117 
   </p><p>The <code class="code">cpu_include_dir</code> sets default locations for the files controlling
118 
<a class="link" href="internals.html#internals.thread_safety" title="Thread Safety">Thread safety</a> and <a class="link" href="internals.html#internals.numeric_limits" title="Numeric Limits">Numeric limits</a>, if the defaults are not
119 
appropriate for your chip.
120 
   </p></div><div class="sect2" title="Character Types"><div class="titlepage"><div><div><h3 class="title"><a id="internals.char_types"></a>Character Types</h3></div></div></div><p>The library requires that you provide three header files to implement
121 
character classification, analogous to that provided by the C libraries
122 
<code class="code">&lt;ctype.h&gt;</code> header.  You can model these on the files provided in
123 
<code class="code">config/os/generic</code>.  However, these files will almost
124 
certainly need some modification.
125 
</p><p>The first file to write is <code class="code">ctype_base.h</code>.  This file provides
126 
some very basic information about character classification.  The libstdc++
127 
library assumes that your C library implements <code class="code">&lt;ctype.h&gt;</code> by using
128 
a table (indexed by character code) containing integers, where each of
129 
these integers is a bit-mask indicating whether the character is
130 
upper-case, lower-case, alphabetic, etc.  The <code class="code">ctype_base.h</code>
131 
file gives the type of the integer, and the values of the various bit
132 
masks.  You will have to peer at your own <code class="code">&lt;ctype.h&gt;</code> to figure out
133 
how to define the values required by this file.
134 
   </p><p>The <code class="code">ctype_base.h</code> header file does not need include guards.
135 
It should contain a single <code class="code">struct</code> definition called
136 
<code class="code">ctype_base</code>.  This <code class="code">struct</code> should contain two type
137 
declarations, and one enumeration declaration, like this example, taken
138 
from the IRIX configuration:
139 
   </p><pre class="programlisting">
140 
  struct ctype_base
141 
     {
142 
       typedef unsigned int     mask;
143 
       typedef int*             __to_type;
144 
 
145 
       enum
146 
       {
147 
         space = _ISspace,
148 
         print = _ISprint,
149 
         cntrl = _IScntrl,
150 
         upper = _ISupper,
151 
         lower = _ISlower,
152 
         alpha = _ISalpha,
153 
         digit = _ISdigit,
154 
         punct = _ISpunct,
155 
         xdigit = _ISxdigit,
156 
         alnum = _ISalnum,
157 
         graph = _ISgraph
158 
       };
159 
     };
160 
</pre><p>The <code class="code">mask</code> type is the type of the elements in the table.  If your
161 
C library uses a table to map lower-case numbers to upper-case numbers,
162 
and vice versa, you should define <code class="code">__to_type</code> to be the type of the
163 
elements in that table.  If you don't mind taking a minor performance
164 
penalty, or if your library doesn't implement <code class="code">toupper</code> and
165 
<code class="code">tolower</code> in this way, you can pick any pointer-to-integer type,
166 
but you must still define the type.
167 
</p><p>The enumeration should give definitions for all the values in the above
168 
example, using the values from your native <code class="code">&lt;ctype.h&gt;</code>.  They can
169 
be given symbolically (as above), or numerically, if you prefer.  You do
170 
not have to include <code class="code">&lt;ctype.h&gt;</code> in this header; it will always be
171 
included before <code class="code">ctype_base.h</code> is included.
172 
   </p><p>The next file to write is <code class="code">ctype_noninline.h</code>, which also does
173 
not require include guards.  This file defines a few member functions
174 
that will be included in <code class="code">include/bits/locale_facets.h</code>.  The first
175 
function that must be written is the <code class="code">ctype&lt;char&gt;::ctype</code>
176 
constructor.  Here is the IRIX example:
177 
   </p><pre class="programlisting">
178 
ctype&lt;char&gt;::ctype(const mask* __table = 0, bool __del = false,
179 
           size_t __refs = 0)
180 
       : _Ctype_nois&lt;char&gt;(__refs), _M_del(__table != 0 &amp;&amp; __del),
181 
         _M_toupper(NULL),
182 
         _M_tolower(NULL),
183 
         _M_ctable(NULL),
184 
         _M_table(!__table
185 
                  ? (const mask*) (__libc_attr._ctype_tbl-&gt;_class + 1)
186 
                  : __table)
187 
       { }
188 
</pre><p>There are two parts of this that you might choose to alter. The first,
189 
and most important, is the line involving <code class="code">__libc_attr</code>.  That is
190 
IRIX system-dependent code that gets the base of the table mapping
191 
character codes to attributes.  You need to substitute code that obtains
192 
the address of this table on your system.  If you want to use your
193 
operating system's tables to map upper-case letters to lower-case, and
194 
vice versa, you should initialize <code class="code">_M_toupper</code> and
195 
<code class="code">_M_tolower</code> with those tables, in similar fashion.
196 
</p><p>Now, you have to write two functions to convert from upper-case to
197 
lower-case, and vice versa.  Here are the IRIX versions:
198 
   </p><pre class="programlisting">
199 
     char
200 
     ctype&lt;char&gt;::do_toupper(char __c) const
201 
     { return _toupper(__c); }
202 
 
203 
     char
204 
     ctype&lt;char&gt;::do_tolower(char __c) const
205 
     { return _tolower(__c); }
206 
</pre><p>Your C library provides equivalents to IRIX's <code class="code">_toupper</code> and
207 
<code class="code">_tolower</code>.  If you initialized <code class="code">_M_toupper</code> and
208 
<code class="code">_M_tolower</code> above, then you could use those tables instead.
209 
</p><p>Finally, you have to provide two utility functions that convert strings
210 
of characters.  The versions provided here will always work - but you
211 
could use specialized routines for greater performance if you have
212 
machinery to do that on your system:
213 
   </p><pre class="programlisting">
214 
     const char*
215 
     ctype&lt;char&gt;::do_toupper(char* __low, const char* __high) const
216 
     {
217 
       while (__low &lt; __high)
218 
         {
219 
           *__low = do_toupper(*__low);
220 
           ++__low;
221 
         }
222 
       return __high;
223 
     }
224 
 
225 
     const char*
226 
     ctype&lt;char&gt;::do_tolower(char* __low, const char* __high) const
227 
     {
228 
       while (__low &lt; __high)
229 
         {
230 
           *__low = do_tolower(*__low);
231 
           ++__low;
232 
         }
233 
       return __high;
234 
     }
235 
</pre><p>You must also provide the <code class="code">ctype_inline.h</code> file, which
236 
contains a few more functions.  On most systems, you can just copy
237 
<code class="code">config/os/generic/ctype_inline.h</code> and use it on your system.
238 
   </p><p>In detail, the functions provided test characters for particular
239 
properties; they are analogous to the functions like <code class="code">isalpha</code> and
240 
<code class="code">islower</code> provided by the C library.
241 
   </p><p>The first function is implemented like this on IRIX:
242 
   </p><pre class="programlisting">
243 
     bool
244 
     ctype&lt;char&gt;::
245 
     is(mask __m, char __c) const throw()
246 
     { return (_M_table)[(unsigned char)(__c)] &amp; __m; }
247 
</pre><p>The <code class="code">_M_table</code> is the table passed in above, in the constructor.
248 
This is the table that contains the bitmasks for each character.  The
249 
implementation here should work on all systems.
250 
</p><p>The next function is:
251 
   </p><pre class="programlisting">
252 
     const char*
253 
     ctype&lt;char&gt;::
254 
     is(const char* __low, const char* __high, mask* __vec) const throw()
255 
     {
256 
       while (__low &lt; __high)
257 
         *__vec++ = (_M_table)[(unsigned char)(*__low++)];
258 
       return __high;
259 
     }
260 
</pre><p>This function is similar; it copies the masks for all the characters
261 
from <code class="code">__low</code> up until <code class="code">__high</code> into the vector given by
262 
<code class="code">__vec</code>.
263 
</p><p>The last two functions again are entirely generic:
264 
   </p><pre class="programlisting">
265 
     const char*
266 
     ctype&lt;char&gt;::
267 
     scan_is(mask __m, const char* __low, const char* __high) const throw()
268 
     {
269 
       while (__low &lt; __high &amp;&amp; !this-&gt;is(__m, *__low))
270 
         ++__low;
271 
       return __low;
272 
     }
273 
 
274 
     const char*
275 
     ctype&lt;char&gt;::
276 
     scan_not(mask __m, const char* __low, const char* __high) const throw()
277 
     {
278 
       while (__low &lt; __high &amp;&amp; this-&gt;is(__m, *__low))
279 
         ++__low;
280 
       return __low;
281 
     }
282 
</pre></div><div class="sect2" title="Thread Safety"><div class="titlepage"><div><div><h3 class="title"><a id="internals.thread_safety"></a>Thread Safety</h3></div></div></div><p>The C++ library string functionality requires a couple of atomic
283 
operations to provide thread-safety.  If you don't take any special
284 
action, the library will use stub versions of these functions that are
285 
not thread-safe.  They will work fine, unless your applications are
286 
multi-threaded.
287 
</p><p>If you want to provide custom, safe, versions of these functions, there
288 
are two distinct approaches.  One is to provide a version for your CPU,
289 
using assembly language constructs.  The other is to use the
290 
thread-safety primitives in your operating system.  In either case, you
291 
make a file called <code class="code">atomicity.h</code>, and the variable
292 
<code class="code">ATOMICITYH</code> must point to this file.
293 
   </p><p>If you are using the assembly-language approach, put this code in
294 
<code class="code">config/cpu/&lt;chip&gt;/atomicity.h</code>, where chip is the name of
295 
your processor (see <a class="link" href="internals.html#internals.cpu" title="CPU">CPU</a>).  No additional changes are necessary to
296 
locate the file in this case; <code class="code">ATOMICITYH</code> will be set by default.
297 
   </p><p>If you are using the operating system thread-safety primitives approach,
298 
you can also put this code in the same CPU directory, in which case no more
299 
work is needed to locate the file.  For examples of this approach,
300 
see the <code class="code">atomicity.h</code> file for IRIX or IA64.
301 
   </p><p>Alternatively, if the primitives are more closely related to the OS
302 
than they are to the CPU, you can put the <code class="code">atomicity.h</code> file in
303 
the <a class="link" href="internals.html#internals.os" title="Operating System">Operating system</a> directory instead.  In this case, you must
304 
edit <code class="code">configure.host</code>, and in the switch statement that handles
305 
operating systems, override the <code class="code">ATOMICITYH</code> variable to point to
306 
the appropriate <code class="code">os_include_dir</code>.  For examples of this approach,
307 
see the <code class="code">atomicity.h</code> file for AIX.
308 
   </p><p>With those bits out of the way, you have to actually write
309 
<code class="code">atomicity.h</code> itself.  This file should be wrapped in an
310 
include guard named <code class="code">_GLIBCXX_ATOMICITY_H</code>.  It should define one
311 
type, and two functions.
312 
   </p><p>The type is <code class="code">_Atomic_word</code>.  Here is the version used on IRIX:
313 
   </p><pre class="programlisting">
314 
typedef long _Atomic_word;
315 
</pre><p>This type must be a signed integral type supporting atomic operations.
316 
If you're using the OS approach, use the same type used by your system's
317 
primitives.  Otherwise, use the type for which your CPU provides atomic
318 
primitives.
319 
</p><p>Then, you must provide two functions.  The bodies of these functions
320 
must be equivalent to those provided here, but using atomic operations:
321 
   </p><pre class="programlisting">
322 
     static inline _Atomic_word
323 
     __attribute__ ((__unused__))
324 
     __exchange_and_add (_Atomic_word* __mem, int __val)
325 
     {
326 
       _Atomic_word __result = *__mem;
327 
       *__mem += __val;
328 
       return __result;
329 
     }
330 
 
331 
     static inline void
332 
     __attribute__ ((__unused__))
333 
     __atomic_add (_Atomic_word* __mem, int __val)
334 
     {
335 
       *__mem += __val;
336 
     }
337 
</pre></div><div class="sect2" title="Numeric Limits"><div class="titlepage"><div><div><h3 class="title"><a id="internals.numeric_limits"></a>Numeric Limits</h3></div></div></div><p>The C++ library requires information about the fundamental data types,
338 
such as the minimum and maximum representable values of each type.
339 
You can define each of these values individually, but it is usually
340 
easiest just to indicate how many bits are used in each of the data
341 
types and let the library do the rest.  For information about the
342 
macros to define, see the top of <code class="code">include/bits/std_limits.h</code>.
343 
</p><p>If you need to define any macros, you can do so in <code class="code">os_defines.h</code>.
344 
However, if all operating systems for your CPU are likely to use the
345 
same values, you can provide a CPU-specific file instead so that you
346 
do not have to provide the same definitions for each operating system.
347 
To take that approach, create a new file called <code class="code">cpu_limits.h</code> in
348 
your CPU configuration directory (see <a class="link" href="internals.html#internals.cpu" title="CPU">CPU</a>).
349 
   </p></div><div class="sect2" title="Libtool"><div class="titlepage"><div><div><h3 class="title"><a id="internals.libtool"></a>Libtool</h3></div></div></div><p>The C++ library is compiled, archived and linked with libtool.
350 
Explaining the full workings of libtool is beyond the scope of this
351 
document, but there are a few, particular bits that are necessary for
352 
porting.
353 
</p><p>Some parts of the libstdc++ library are compiled with the libtool
354 
<code class="code">--tags CXX</code> option (the C++ definitions for libtool).  Therefore,
355 
<code class="code">ltcf-cxx.sh</code> in the top-level directory needs to have the correct
356 
logic to compile and archive objects equivalent to the C version of libtool,
357 
<code class="code">ltcf-c.sh</code>.  Some libtool targets have definitions for C but not
358 
for C++, or C++ definitions which have not been kept up to date.
359 
   </p><p>The C++ run-time library contains initialization code that needs to be
360 
run as the library is loaded.  Often, that requires linking in special
361 
object files when the C++ library is built as a shared library, or
362 
taking other system-specific actions.
363 
   </p><p>The libstdc++ library is linked with the C version of libtool, even
364 
though it is a C++ library.  Therefore, the C version of libtool needs to
365 
ensure that the run-time library initializers are run.  The usual way to
366 
do this is to build the library using <code class="code">gcc -shared</code>.
367 
   </p><p>If you need to change how the library is linked, look at
368 
<code class="code">ltcf-c.sh</code> in the top-level directory.  Find the switch statement
369 
that sets <code class="code">archive_cmds</code>.  Here, adjust the setting for your
370 
operating system.
371 
   </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="appendix_porting.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="test.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix B. 
372 
  Porting and Maintenance
373 
 
374 
 </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> Test</td></tr></table></div></body></html>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.