1 | This is Info file gcc.info, produced by Makeinfo version 1.67 from the |
---|
2 | input file gcc.texi. |
---|
3 | |
---|
4 | This file documents the use and the internals of the GNU compiler. |
---|
5 | |
---|
6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 |
---|
7 | Boston, MA 02111-1307 USA |
---|
8 | |
---|
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998 |
---|
10 | Free Software Foundation, Inc. |
---|
11 | |
---|
12 | Permission is granted to make and distribute verbatim copies of this |
---|
13 | manual provided the copyright notice and this permission notice are |
---|
14 | preserved on all copies. |
---|
15 | |
---|
16 | Permission is granted to copy and distribute modified versions of |
---|
17 | this manual under the conditions for verbatim copying, provided also |
---|
18 | that the sections entitled "GNU General Public License," "Funding for |
---|
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are |
---|
20 | included exactly as in the original, and provided that the entire |
---|
21 | resulting derived work is distributed under the terms of a permission |
---|
22 | notice identical to this one. |
---|
23 | |
---|
24 | Permission is granted to copy and distribute translations of this |
---|
25 | manual into another language, under the above conditions for modified |
---|
26 | versions, except that the sections entitled "GNU General Public |
---|
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight |
---|
28 | `Look And Feel'", and this permission notice, may be included in |
---|
29 | translations approved by the Free Software Foundation instead of in the |
---|
30 | original English. |
---|
31 | |
---|
32 | |
---|
33 | File: gcc.info, Node: Misc, Prev: Cross-compilation, Up: Target Macros |
---|
34 | |
---|
35 | Miscellaneous Parameters |
---|
36 | ======================== |
---|
37 | |
---|
38 | Here are several miscellaneous parameters. |
---|
39 | |
---|
40 | `PREDICATE_CODES' |
---|
41 | Define this if you have defined special-purpose predicates in the |
---|
42 | file `MACHINE.c'. This macro is called within an initializer of an |
---|
43 | array of structures. The first field in the structure is the name |
---|
44 | of a predicate and the second field is an array of rtl codes. For |
---|
45 | each predicate, list all rtl codes that can be in expressions |
---|
46 | matched by the predicate. The list should have a trailing comma. |
---|
47 | Here is an example of two entries in the list for a typical RISC |
---|
48 | machine: |
---|
49 | |
---|
50 | #define PREDICATE_CODES \ |
---|
51 | {"gen_reg_rtx_operand", {SUBREG, REG}}, \ |
---|
52 | {"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}}, |
---|
53 | |
---|
54 | Defining this macro does not affect the generated code (however, |
---|
55 | incorrect definitions that omit an rtl code that may be matched by |
---|
56 | the predicate can cause the compiler to malfunction). Instead, it |
---|
57 | allows the table built by `genrecog' to be more compact and |
---|
58 | efficient, thus speeding up the compiler. The most important |
---|
59 | predicates to include in the list specified by this macro are |
---|
60 | those used in the most insn patterns. |
---|
61 | |
---|
62 | `CASE_VECTOR_MODE' |
---|
63 | An alias for a machine mode name. This is the machine mode that |
---|
64 | elements of a jump-table should have. |
---|
65 | |
---|
66 | `CASE_VECTOR_PC_RELATIVE' |
---|
67 | Define this macro if jump-tables should contain relative addresses. |
---|
68 | |
---|
69 | `CASE_DROPS_THROUGH' |
---|
70 | Define this if control falls through a `case' insn when the index |
---|
71 | value is out of range. This means the specified default-label is |
---|
72 | actually ignored by the `case' insn proper. |
---|
73 | |
---|
74 | `CASE_VALUES_THRESHOLD' |
---|
75 | Define this to be the smallest number of different values for |
---|
76 | which it is best to use a jump-table instead of a tree of |
---|
77 | conditional branches. The default is four for machines with a |
---|
78 | `casesi' instruction and five otherwise. This is best for most |
---|
79 | machines. |
---|
80 | |
---|
81 | `WORD_REGISTER_OPERATIONS' |
---|
82 | Define this macro if operations between registers with integral |
---|
83 | mode smaller than a word are always performed on the entire |
---|
84 | register. Most RISC machines have this property and most CISC |
---|
85 | machines do not. |
---|
86 | |
---|
87 | `LOAD_EXTEND_OP (MODE)' |
---|
88 | Define this macro to be a C expression indicating when insns that |
---|
89 | read memory in MODE, an integral mode narrower than a word, set the |
---|
90 | bits outside of MODE to be either the sign-extension or the |
---|
91 | zero-extension of the data read. Return `SIGN_EXTEND' for values |
---|
92 | of MODE for which the insn sign-extends, `ZERO_EXTEND' for which |
---|
93 | it zero-extends, and `NIL' for other modes. |
---|
94 | |
---|
95 | This macro is not called with MODE non-integral or with a width |
---|
96 | greater than or equal to `BITS_PER_WORD', so you may return any |
---|
97 | value in this case. Do not define this macro if it would always |
---|
98 | return `NIL'. On machines where this macro is defined, you will |
---|
99 | normally define it as the constant `SIGN_EXTEND' or `ZERO_EXTEND'. |
---|
100 | |
---|
101 | `SHORT_IMMEDIATES_SIGN_EXTEND' |
---|
102 | Define this macro if loading short immediate values into registers |
---|
103 | sign extends. |
---|
104 | |
---|
105 | `IMPLICIT_FIX_EXPR' |
---|
106 | An alias for a tree code that should be used by default for |
---|
107 | conversion of floating point values to fixed point. Normally, |
---|
108 | `FIX_ROUND_EXPR' is used. |
---|
109 | |
---|
110 | `FIXUNS_TRUNC_LIKE_FIX_TRUNC' |
---|
111 | Define this macro if the same instructions that convert a floating |
---|
112 | point number to a signed fixed point number also convert validly |
---|
113 | to an unsigned one. |
---|
114 | |
---|
115 | `EASY_DIV_EXPR' |
---|
116 | An alias for a tree code that is the easiest kind of division to |
---|
117 | compile code for in the general case. It may be `TRUNC_DIV_EXPR', |
---|
118 | `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or `ROUND_DIV_EXPR'. These four |
---|
119 | division operators differ in how they round the result to an |
---|
120 | integer. `EASY_DIV_EXPR' is used when it is permissible to use |
---|
121 | any of those kinds of division and the choice should be made on |
---|
122 | the basis of efficiency. |
---|
123 | |
---|
124 | `MOVE_MAX' |
---|
125 | The maximum number of bytes that a single instruction can move |
---|
126 | quickly between memory and registers or between two memory |
---|
127 | locations. |
---|
128 | |
---|
129 | `MAX_MOVE_MAX' |
---|
130 | The maximum number of bytes that a single instruction can move |
---|
131 | quickly between memory and registers or between two memory |
---|
132 | locations. If this is undefined, the default is `MOVE_MAX'. |
---|
133 | Otherwise, it is the constant value that is the largest value that |
---|
134 | `MOVE_MAX' can have at run-time. |
---|
135 | |
---|
136 | `SHIFT_COUNT_TRUNCATED' |
---|
137 | A C expression that is nonzero if on this machine the number of |
---|
138 | bits actually used for the count of a shift operation is equal to |
---|
139 | the number of bits needed to represent the size of the object |
---|
140 | being shifted. When this macro is non-zero, the compiler will |
---|
141 | assume that it is safe to omit a sign-extend, zero-extend, and |
---|
142 | certain bitwise `and' instructions that truncates the count of a |
---|
143 | shift operation. On machines that have instructions that act on |
---|
144 | bitfields at variable positions, which may include `bit test' |
---|
145 | instructions, a nonzero `SHIFT_COUNT_TRUNCATED' also enables |
---|
146 | deletion of truncations of the values that serve as arguments to |
---|
147 | bitfield instructions. |
---|
148 | |
---|
149 | If both types of instructions truncate the count (for shifts) and |
---|
150 | position (for bitfield operations), or if no variable-position |
---|
151 | bitfield instructions exist, you should define this macro. |
---|
152 | |
---|
153 | However, on some machines, such as the 80386 and the 680x0, |
---|
154 | truncation only applies to shift operations and not the (real or |
---|
155 | pretended) bitfield operations. Define `SHIFT_COUNT_TRUNCATED' to |
---|
156 | be zero on such machines. Instead, add patterns to the `md' file |
---|
157 | that include the implied truncation of the shift instructions. |
---|
158 | |
---|
159 | You need not define this macro if it would always have the value |
---|
160 | of zero. |
---|
161 | |
---|
162 | `TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)' |
---|
163 | A C expression which is nonzero if on this machine it is safe to |
---|
164 | "convert" an integer of INPREC bits to one of OUTPREC bits (where |
---|
165 | OUTPREC is smaller than INPREC) by merely operating on it as if it |
---|
166 | had only OUTPREC bits. |
---|
167 | |
---|
168 | On many machines, this expression can be 1. |
---|
169 | |
---|
170 | When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for |
---|
171 | modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result. |
---|
172 | If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in |
---|
173 | such cases may improve things. |
---|
174 | |
---|
175 | `STORE_FLAG_VALUE' |
---|
176 | A C expression describing the value returned by a comparison |
---|
177 | operator with an integral mode and stored by a store-flag |
---|
178 | instruction (`sCOND') when the condition is true. This |
---|
179 | description must apply to *all* the `sCOND' patterns and all the |
---|
180 | comparison operators whose results have a `MODE_INT' mode. |
---|
181 | |
---|
182 | A value of 1 or -1 means that the instruction implementing the |
---|
183 | comparison operator returns exactly 1 or -1 when the comparison is |
---|
184 | true and 0 when the comparison is false. Otherwise, the value |
---|
185 | indicates which bits of the result are guaranteed to be 1 when the |
---|
186 | comparison is true. This value is interpreted in the mode of the |
---|
187 | comparison operation, which is given by the mode of the first |
---|
188 | operand in the `sCOND' pattern. Either the low bit or the sign |
---|
189 | bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are |
---|
190 | used by the compiler. |
---|
191 | |
---|
192 | If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will |
---|
193 | generate code that depends only on the specified bits. It can also |
---|
194 | replace comparison operators with equivalent operations if they |
---|
195 | cause the required bits to be set, even if the remaining bits are |
---|
196 | undefined. For example, on a machine whose comparison operators |
---|
197 | return an `SImode' value and where `STORE_FLAG_VALUE' is defined as |
---|
198 | `0x80000000', saying that just the sign bit is relevant, the |
---|
199 | expression |
---|
200 | |
---|
201 | (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0)) |
---|
202 | |
---|
203 | can be converted to |
---|
204 | |
---|
205 | (ashift:SI X (const_int N)) |
---|
206 | |
---|
207 | where N is the appropriate shift count to move the bit being |
---|
208 | tested into the sign bit. |
---|
209 | |
---|
210 | There is no way to describe a machine that always sets the |
---|
211 | low-order bit for a true value, but does not guarantee the value |
---|
212 | of any other bits, but we do not know of any machine that has such |
---|
213 | an instruction. If you are trying to port GNU CC to such a |
---|
214 | machine, include an instruction to perform a logical-and of the |
---|
215 | result with 1 in the pattern for the comparison operators and let |
---|
216 | us know (*note How to Report Bugs: Bug Reporting.). |
---|
217 | |
---|
218 | Often, a machine will have multiple instructions that obtain a |
---|
219 | value from a comparison (or the condition codes). Here are rules |
---|
220 | to guide the choice of value for `STORE_FLAG_VALUE', and hence the |
---|
221 | instructions to be used: |
---|
222 | |
---|
223 | * Use the shortest sequence that yields a valid definition for |
---|
224 | `STORE_FLAG_VALUE'. It is more efficient for the compiler to |
---|
225 | "normalize" the value (convert it to, e.g., 1 or 0) than for |
---|
226 | the comparison operators to do so because there may be |
---|
227 | opportunities to combine the normalization with other |
---|
228 | operations. |
---|
229 | |
---|
230 | * For equal-length sequences, use a value of 1 or -1, with -1 |
---|
231 | being slightly preferred on machines with expensive jumps and |
---|
232 | 1 preferred on other machines. |
---|
233 | |
---|
234 | * As a second choice, choose a value of `0x80000001' if |
---|
235 | instructions exist that set both the sign and low-order bits |
---|
236 | but do not define the others. |
---|
237 | |
---|
238 | * Otherwise, use a value of `0x80000000'. |
---|
239 | |
---|
240 | Many machines can produce both the value chosen for |
---|
241 | `STORE_FLAG_VALUE' and its negation in the same number of |
---|
242 | instructions. On those machines, you should also define a pattern |
---|
243 | for those cases, e.g., one matching |
---|
244 | |
---|
245 | (set A (neg:M (ne:M B C))) |
---|
246 | |
---|
247 | Some machines can also perform `and' or `plus' operations on |
---|
248 | condition code values with less instructions than the corresponding |
---|
249 | `sCOND' insn followed by `and' or `plus'. On those machines, |
---|
250 | define the appropriate patterns. Use the names `incscc' and |
---|
251 | `decscc', respectively, for the patterns which perform `plus' or |
---|
252 | `minus' operations on condition code values. See `rs6000.md' for |
---|
253 | some examples. The GNU Superoptizer can be used to find such |
---|
254 | instruction sequences on other machines. |
---|
255 | |
---|
256 | You need not define `STORE_FLAG_VALUE' if the machine has no |
---|
257 | store-flag instructions. |
---|
258 | |
---|
259 | `FLOAT_STORE_FLAG_VALUE' |
---|
260 | A C expression that gives a non-zero floating point value that is |
---|
261 | returned when comparison operators with floating-point results are |
---|
262 | true. Define this macro on machine that have comparison |
---|
263 | operations that return floating-point values. If there are no |
---|
264 | such operations, do not define this macro. |
---|
265 | |
---|
266 | `Pmode' |
---|
267 | An alias for the machine mode for pointers. On most machines, |
---|
268 | define this to be the integer mode corresponding to the width of a |
---|
269 | hardware pointer; `SImode' on 32-bit machine or `DImode' on 64-bit |
---|
270 | machines. On some machines you must define this to be one of the |
---|
271 | partial integer modes, such as `PSImode'. |
---|
272 | |
---|
273 | The width of `Pmode' must be at least as large as the value of |
---|
274 | `POINTER_SIZE'. If it is not equal, you must define the macro |
---|
275 | `POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to |
---|
276 | `Pmode'. |
---|
277 | |
---|
278 | `FUNCTION_MODE' |
---|
279 | An alias for the machine mode used for memory references to |
---|
280 | functions being called, in `call' RTL expressions. On most |
---|
281 | machines this should be `QImode'. |
---|
282 | |
---|
283 | `INTEGRATE_THRESHOLD (DECL)' |
---|
284 | A C expression for the maximum number of instructions above which |
---|
285 | the function DECL should not be inlined. DECL is a |
---|
286 | `FUNCTION_DECL' node. |
---|
287 | |
---|
288 | The default definition of this macro is 64 plus 8 times the number |
---|
289 | of arguments that the function accepts. Some people think a larger |
---|
290 | threshold should be used on RISC machines. |
---|
291 | |
---|
292 | `SCCS_DIRECTIVE' |
---|
293 | Define this if the preprocessor should ignore `#sccs' directives |
---|
294 | and print no error message. |
---|
295 | |
---|
296 | `NO_IMPLICIT_EXTERN_C' |
---|
297 | Define this macro if the system header files support C++ as well |
---|
298 | as C. This macro inhibits the usual method of using system header |
---|
299 | files in C++, which is to pretend that the file's contents are |
---|
300 | enclosed in `extern "C" {...}'. |
---|
301 | |
---|
302 | `HANDLE_PRAGMA (STREAM, NODE)' |
---|
303 | Define this macro if you want to implement any pragmas. If |
---|
304 | defined, it is a C expression whose value is 1 if the pragma was |
---|
305 | handled by the function. The argument STREAM is the stdio input |
---|
306 | stream from which the source text can be read. NODE is the tree |
---|
307 | node for the identifier after the `#pragma'. |
---|
308 | |
---|
309 | It is generally a bad idea to implement new uses of `#pragma'. The |
---|
310 | only reason to define this macro is for compatibility with other |
---|
311 | compilers that do support `#pragma' for the sake of any user |
---|
312 | programs which already use it. |
---|
313 | |
---|
314 | `VALID_MACHINE_DECL_ATTRIBUTE (DECL, ATTRIBUTES, IDENTIFIER, ARGS)' |
---|
315 | If defined, a C expression whose value is nonzero if IDENTIFIER |
---|
316 | with arguments ARGS is a valid machine specific attribute for DECL. |
---|
317 | The attributes in ATTRIBUTES have previously been assigned to DECL. |
---|
318 | |
---|
319 | `VALID_MACHINE_TYPE_ATTRIBUTE (TYPE, ATTRIBUTES, IDENTIFIER, ARGS)' |
---|
320 | If defined, a C expression whose value is nonzero if IDENTIFIER |
---|
321 | with arguments ARGS is a valid machine specific attribute for TYPE. |
---|
322 | The attributes in ATTRIBUTES have previously been assigned to TYPE. |
---|
323 | |
---|
324 | `COMP_TYPE_ATTRIBUTES (TYPE1, TYPE2)' |
---|
325 | If defined, a C expression whose value is zero if the attributes on |
---|
326 | TYPE1 and TYPE2 are incompatible, one if they are compatible, and |
---|
327 | two if they are nearly compatible (which causes a warning to be |
---|
328 | generated). |
---|
329 | |
---|
330 | `SET_DEFAULT_TYPE_ATTRIBUTES (TYPE)' |
---|
331 | If defined, a C statement that assigns default attributes to newly |
---|
332 | defined TYPE. |
---|
333 | |
---|
334 | `DOLLARS_IN_IDENTIFIERS' |
---|
335 | Define this macro to control use of the character `$' in identifier |
---|
336 | names. 0 means `$' is not allowed by default; 1 means it is |
---|
337 | allowed. 1 is the default; there is no need to define this macro |
---|
338 | in that case. This macro controls the compiler proper; it does |
---|
339 | not affect the preprocessor. |
---|
340 | |
---|
341 | `NO_DOLLAR_IN_LABEL' |
---|
342 | Define this macro if the assembler does not accept the character |
---|
343 | `$' in label names. By default constructors and destructors in |
---|
344 | G++ have `$' in the identifiers. If this macro is defined, `.' is |
---|
345 | used instead. |
---|
346 | |
---|
347 | `NO_DOT_IN_LABEL' |
---|
348 | Define this macro if the assembler does not accept the character |
---|
349 | `.' in label names. By default constructors and destructors in G++ |
---|
350 | have names that use `.'. If this macro is defined, these names |
---|
351 | are rewritten to avoid `.'. |
---|
352 | |
---|
353 | `DEFAULT_MAIN_RETURN' |
---|
354 | Define this macro if the target system expects every program's |
---|
355 | `main' function to return a standard "success" value by default |
---|
356 | (if no other value is explicitly returned). |
---|
357 | |
---|
358 | The definition should be a C statement (sans semicolon) to |
---|
359 | generate the appropriate rtl instructions. It is used only when |
---|
360 | compiling the end of `main'. |
---|
361 | |
---|
362 | `HAVE_ATEXIT' |
---|
363 | Define this if the target system supports the function `atexit' |
---|
364 | from the ANSI C standard. If this is not defined, and |
---|
365 | `INIT_SECTION_ASM_OP' is not defined, a default `exit' function |
---|
366 | will be provided to support C++. |
---|
367 | |
---|
368 | `EXIT_BODY' |
---|
369 | Define this if your `exit' function needs to do something besides |
---|
370 | calling an external function `_cleanup' before terminating with |
---|
371 | `_exit'. The `EXIT_BODY' macro is only needed if neither |
---|
372 | `HAVE_ATEXIT' nor `INIT_SECTION_ASM_OP' are defined. |
---|
373 | |
---|
374 | `INSN_SETS_ARE_DELAYED (INSN)' |
---|
375 | Define this macro as a C expression that is nonzero if it is safe |
---|
376 | for the delay slot scheduler to place instructions in the delay |
---|
377 | slot of INSN, even if they appear to use a resource set or |
---|
378 | clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GNU |
---|
379 | CC knows that every `call_insn' has this behavior. On machines |
---|
380 | where some `insn' or `jump_insn' is really a function call and |
---|
381 | hence has this behavior, you should define this macro. |
---|
382 | |
---|
383 | You need not define this macro if it would always return zero. |
---|
384 | |
---|
385 | `INSN_REFERENCES_ARE_DELAYED (INSN)' |
---|
386 | Define this macro as a C expression that is nonzero if it is safe |
---|
387 | for the delay slot scheduler to place instructions in the delay |
---|
388 | slot of INSN, even if they appear to set or clobber a resource |
---|
389 | referenced in INSN. INSN is always a `jump_insn' or an `insn'. |
---|
390 | On machines where some `insn' or `jump_insn' is really a function |
---|
391 | call and its operands are registers whose use is actually in the |
---|
392 | subroutine it calls, you should define this macro. Doing so |
---|
393 | allows the delay slot scheduler to move instructions which copy |
---|
394 | arguments into the argument registers into the delay slot of INSN. |
---|
395 | |
---|
396 | You need not define this macro if it would always return zero. |
---|
397 | |
---|
398 | `MACHINE_DEPENDENT_REORG (INSN)' |
---|
399 | In rare cases, correct code generation requires extra machine |
---|
400 | dependent processing between the second jump optimization pass and |
---|
401 | delayed branch scheduling. On those machines, define this macro |
---|
402 | as a C statement to act on the code starting at INSN. |
---|
403 | |
---|
404 | `MULTIPLE_SYMBOL_SPACES' |
---|
405 | Define this macro if in some cases global symbols from one |
---|
406 | translation unit may not be bound to undefined symbols in another |
---|
407 | translation unit without user intervention. For instance, under |
---|
408 | Microsoft Windows symbols must be explicitly imported from shared |
---|
409 | libraries (DLLs). |
---|
410 | |
---|
411 | `GIV_SORT_CRITERION (GIV1, GIV2)' |
---|
412 | In some cases, the strength reduction optimization pass can |
---|
413 | produce better code if this is defined. This macro controls the |
---|
414 | order that induction variables are combined. This macro is |
---|
415 | particularly useful if the target has limited addressing modes. |
---|
416 | For instance, the SH target has only positive offsets in |
---|
417 | addresses. Thus sorting to put the smallest address first allows |
---|
418 | the most combinations to be found. |
---|
419 | |
---|
420 | |
---|
421 | File: gcc.info, Node: Config, Next: Fragments, Prev: Target Macros, Up: Top |
---|
422 | |
---|
423 | The Configuration File |
---|
424 | ********************** |
---|
425 | |
---|
426 | The configuration file `xm-MACHINE.h' contains macro definitions |
---|
427 | that describe the machine and system on which the compiler is running, |
---|
428 | unlike the definitions in `MACHINE.h', which describe the machine for |
---|
429 | which the compiler is producing output. Most of the values in |
---|
430 | `xm-MACHINE.h' are actually the same on all machines that GNU CC runs |
---|
431 | on, so large parts of all configuration files are identical. But there |
---|
432 | are some macros that vary: |
---|
433 | |
---|
434 | `USG' |
---|
435 | Define this macro if the host system is System V. |
---|
436 | |
---|
437 | `VMS' |
---|
438 | Define this macro if the host system is VMS. |
---|
439 | |
---|
440 | `FATAL_EXIT_CODE' |
---|
441 | A C expression for the status code to be returned when the compiler |
---|
442 | exits after serious errors. |
---|
443 | |
---|
444 | `SUCCESS_EXIT_CODE' |
---|
445 | A C expression for the status code to be returned when the compiler |
---|
446 | exits without serious errors. |
---|
447 | |
---|
448 | `HOST_WORDS_BIG_ENDIAN' |
---|
449 | Defined if the host machine stores words of multi-word values in |
---|
450 | big-endian order. (GNU CC does not depend on the host byte |
---|
451 | ordering within a word.) |
---|
452 | |
---|
453 | `HOST_FLOAT_WORDS_BIG_ENDIAN' |
---|
454 | Define this macro to be 1 if the host machine stores `DFmode', |
---|
455 | `XFmode' or `TFmode' floating point numbers in memory with the |
---|
456 | word containing the sign bit at the lowest address; otherwise, |
---|
457 | define it to be zero. |
---|
458 | |
---|
459 | This macro need not be defined if the ordering is the same as for |
---|
460 | multi-word integers. |
---|
461 | |
---|
462 | `HOST_FLOAT_FORMAT' |
---|
463 | A numeric code distinguishing the floating point format for the |
---|
464 | host machine. See `TARGET_FLOAT_FORMAT' in *Note Storage Layout:: |
---|
465 | for the alternatives and default. |
---|
466 | |
---|
467 | `HOST_BITS_PER_CHAR' |
---|
468 | A C expression for the number of bits in `char' on the host |
---|
469 | machine. |
---|
470 | |
---|
471 | `HOST_BITS_PER_SHORT' |
---|
472 | A C expression for the number of bits in `short' on the host |
---|
473 | machine. |
---|
474 | |
---|
475 | `HOST_BITS_PER_INT' |
---|
476 | A C expression for the number of bits in `int' on the host machine. |
---|
477 | |
---|
478 | `HOST_BITS_PER_LONG' |
---|
479 | A C expression for the number of bits in `long' on the host |
---|
480 | machine. |
---|
481 | |
---|
482 | `ONLY_INT_FIELDS' |
---|
483 | Define this macro to indicate that the host compiler only supports |
---|
484 | `int' bit fields, rather than other integral types, including |
---|
485 | `enum', as do most C compilers. |
---|
486 | |
---|
487 | `OBSTACK_CHUNK_SIZE' |
---|
488 | A C expression for the size of ordinary obstack chunks. If you |
---|
489 | don't define this, a usually-reasonable default is used. |
---|
490 | |
---|
491 | `OBSTACK_CHUNK_ALLOC' |
---|
492 | The function used to allocate obstack chunks. If you don't define |
---|
493 | this, `xmalloc' is used. |
---|
494 | |
---|
495 | `OBSTACK_CHUNK_FREE' |
---|
496 | The function used to free obstack chunks. If you don't define |
---|
497 | this, `free' is used. |
---|
498 | |
---|
499 | `USE_C_ALLOCA' |
---|
500 | Define this macro to indicate that the compiler is running with the |
---|
501 | `alloca' implemented in C. This version of `alloca' can be found |
---|
502 | in the file `alloca.c'; to use it, you must also alter the |
---|
503 | `Makefile' variable `ALLOCA'. (This is done automatically for the |
---|
504 | systems on which we know it is needed.) |
---|
505 | |
---|
506 | If you do define this macro, you should probably do it as follows: |
---|
507 | |
---|
508 | #ifndef __GNUC__ |
---|
509 | #define USE_C_ALLOCA |
---|
510 | #else |
---|
511 | #define alloca __builtin_alloca |
---|
512 | #endif |
---|
513 | |
---|
514 | so that when the compiler is compiled with GNU CC it uses the more |
---|
515 | efficient built-in `alloca' function. |
---|
516 | |
---|
517 | `FUNCTION_CONVERSION_BUG' |
---|
518 | Define this macro to indicate that the host compiler does not |
---|
519 | properly handle converting a function value to a |
---|
520 | pointer-to-function when it is used in an expression. |
---|
521 | |
---|
522 | `MULTIBYTE_CHARS' |
---|
523 | Define this macro to enable support for multibyte characters in the |
---|
524 | input to GNU CC. This requires that the host system support the |
---|
525 | ANSI C library functions for converting multibyte characters to |
---|
526 | wide characters. |
---|
527 | |
---|
528 | `POSIX' |
---|
529 | Define this if your system is POSIX.1 compliant. |
---|
530 | |
---|
531 | `NO_SYS_SIGLIST' |
---|
532 | Define this if your system *does not* provide the variable |
---|
533 | `sys_siglist'. |
---|
534 | |
---|
535 | Some systems do provide this variable, but with a different name |
---|
536 | such as `_sys_siglist'. On these systems, you can define |
---|
537 | `sys_siglist' as a macro which expands into the name actually |
---|
538 | provided. |
---|
539 | |
---|
540 | Autoconf normally defines `SYS_SIGLIST_DECLARED' when it finds a |
---|
541 | declaration of `sys_siglist' in the system header files. However, |
---|
542 | when you define `sys_siglist' to a different name autoconf will |
---|
543 | not automatically define `SYS_SIGLIST_DECLARED'. Therefore, if |
---|
544 | you define `sys_siglist', you should also define |
---|
545 | `SYS_SIGLIST_DECLARED'. |
---|
546 | |
---|
547 | `USE_PROTOTYPES' |
---|
548 | Define this to be 1 if you know that the host compiler supports |
---|
549 | prototypes, even if it doesn't define __STDC__, or define it to be |
---|
550 | 0 if you do not want any prototypes used in compiling GNU CC. If |
---|
551 | `USE_PROTOTYPES' is not defined, it will be determined |
---|
552 | automatically whether your compiler supports prototypes by |
---|
553 | checking if `__STDC__' is defined. |
---|
554 | |
---|
555 | `NO_MD_PROTOTYPES' |
---|
556 | Define this if you wish suppression of prototypes generated from |
---|
557 | the machine description file, but to use other prototypes within |
---|
558 | GNU CC. If `USE_PROTOTYPES' is defined to be 0, or the host |
---|
559 | compiler does not support prototypes, this macro has no effect. |
---|
560 | |
---|
561 | `MD_CALL_PROTOTYPES' |
---|
562 | Define this if you wish to generate prototypes for the `gen_call' |
---|
563 | or `gen_call_value' functions generated from the machine |
---|
564 | description file. If `USE_PROTOTYPES' is defined to be 0, or the |
---|
565 | host compiler does not support prototypes, or `NO_MD_PROTOTYPES' |
---|
566 | is defined, this macro has no effect. As soon as all of the |
---|
567 | machine descriptions are modified to have the appropriate number |
---|
568 | of arguments, this macro will be removed. |
---|
569 | |
---|
570 | `NO_STAB_H' |
---|
571 | Define this if your system does not have the include file |
---|
572 | `stab.h'. If `USG' is defined, `NO_STAB_H' is assumed. |
---|
573 | |
---|
574 | `PATH_SEPARATOR' |
---|
575 | Define this macro to be a C character constant representing the |
---|
576 | character used to separate components in paths. The default value |
---|
577 | is the colon character |
---|
578 | |
---|
579 | `DIR_SEPARATOR' |
---|
580 | If your system uses some character other than slash to separate |
---|
581 | directory names within a file specification, define this macro to |
---|
582 | be a C character constant specifying that character. When GNU CC |
---|
583 | displays file names, the character you specify will be used. GNU |
---|
584 | CC will test for both slash and the character you specify when |
---|
585 | parsing filenames. |
---|
586 | |
---|
587 | `OBJECT_SUFFIX' |
---|
588 | Define this macro to be a C string representing the suffix for |
---|
589 | object files on your machine. If you do not define this macro, |
---|
590 | GNU CC will use `.o' as the suffix for object files. |
---|
591 | |
---|
592 | `EXECUTABLE_SUFFIX' |
---|
593 | Define this macro to be a C string representing the suffix for |
---|
594 | executable files on your machine. If you do not define this |
---|
595 | macro, GNU CC will use the null string as the suffix for object |
---|
596 | files. |
---|
597 | |
---|
598 | `COLLECT_EXPORT_LIST' |
---|
599 | If defined, `collect2' will scan the individual object files |
---|
600 | specified on its command line and create an export list for the |
---|
601 | linker. Define this macro for systems like AIX, where the linker |
---|
602 | discards object files that are not referenced from `main' and uses |
---|
603 | export lists. |
---|
604 | |
---|
605 | In addition, configuration files for system V define `bcopy', |
---|
606 | `bzero' and `bcmp' as aliases. Some files define `alloca' as a macro |
---|
607 | when compiled with GNU CC, in order to take advantage of the benefit of |
---|
608 | GNU CC's built-in `alloca'. |
---|
609 | |
---|
610 | |
---|
611 | File: gcc.info, Node: Fragments, Next: Funding, Prev: Config, Up: Top |
---|
612 | |
---|
613 | Makefile Fragments |
---|
614 | ****************** |
---|
615 | |
---|
616 | When you configure GNU CC using the `configure' script (*note |
---|
617 | Installation::.), it will construct the file `Makefile' from the |
---|
618 | template file `Makefile.in'. When it does this, it will incorporate |
---|
619 | makefile fragment files from the `config' directory, named `t-TARGET' |
---|
620 | and `x-HOST'. If these files do not exist, it means nothing needs to |
---|
621 | be added for a given target or host. |
---|
622 | |
---|
623 | * Menu: |
---|
624 | |
---|
625 | * Target Fragment:: Writing the `t-TARGET' file. |
---|
626 | * Host Fragment:: Writing the `x-HOST' file. |
---|
627 | |
---|
628 | |
---|
629 | File: gcc.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments |
---|
630 | |
---|
631 | The Target Makefile Fragment |
---|
632 | ============================ |
---|
633 | |
---|
634 | The target makefile fragment, `t-TARGET', defines special target |
---|
635 | dependent variables and targets used in the `Makefile': |
---|
636 | |
---|
637 | `LIBGCC1' |
---|
638 | The rule to use to build `libgcc1.a'. If your target does not |
---|
639 | need to use the functions in `libgcc1.a', set this to empty. |
---|
640 | *Note Interface::. |
---|
641 | |
---|
642 | `CROSS_LIBGCC1' |
---|
643 | The rule to use to build `libgcc1.a' when building a cross |
---|
644 | compiler. If your target does not need to use the functions in |
---|
645 | `libgcc1.a', set this to empty. *Note Cross Runtime::. |
---|
646 | |
---|
647 | `LIBGCC2_CFLAGS' |
---|
648 | Compiler flags to use when compiling `libgcc2.c'. |
---|
649 | |
---|
650 | `LIB2FUNCS_EXTRA' |
---|
651 | A list of source file names to be compiled or assembled and |
---|
652 | inserted into `libgcc.a'. |
---|
653 | |
---|
654 | `CRTSTUFF_T_CFLAGS' |
---|
655 | Special flags used when compiling `crtstuff.c'. *Note |
---|
656 | Initialization::. |
---|
657 | |
---|
658 | `CRTSTUFF_T_CFLAGS_S' |
---|
659 | Special flags used when compiling `crtstuff.c' for shared linking. |
---|
660 | Used if you use `crtbeginS.o' and `crtendS.o' in `EXTRA-PARTS'. |
---|
661 | *Note Initialization::. |
---|
662 | |
---|
663 | `MULTILIB_OPTIONS' |
---|
664 | For some targets, invoking GNU CC in different ways produces |
---|
665 | objects that can not be linked together. For example, for some |
---|
666 | targets GNU CC produces both big and little endian code. For |
---|
667 | these targets, you must arrange for multiple versions of |
---|
668 | `libgcc.a' to be compiled, one for each set of incompatible |
---|
669 | options. When GNU CC invokes the linker, it arranges to link in |
---|
670 | the right version of `libgcc.a', based on the command line options |
---|
671 | used. |
---|
672 | |
---|
673 | The `MULTILIB_OPTIONS' macro lists the set of options for which |
---|
674 | special versions of `libgcc.a' must be built. Write options that |
---|
675 | are mutually incompatible side by side, separated by a slash. |
---|
676 | Write options that may be used together separated by a space. The |
---|
677 | build procedure will build all combinations of compatible options. |
---|
678 | |
---|
679 | For example, if you set `MULTILIB_OPTIONS' to `m68000/m68020 |
---|
680 | msoft-float', `Makefile' will build special versions of `libgcc.a' |
---|
681 | using the sets of options `-m68000', `-m68020', `-msoft-float', |
---|
682 | `-m68000 -msoft-float', and `-m68020 -msoft-float'. |
---|
683 | |
---|
684 | `MULTILIB_DIRNAMES' |
---|
685 | If `MULTILIB_OPTIONS' is used, this variable specifies the |
---|
686 | directory names that should be used to hold the various libraries. |
---|
687 | Write one element in `MULTILIB_DIRNAMES' for each element in |
---|
688 | `MULTILIB_OPTIONS'. If `MULTILIB_DIRNAMES' is not used, the |
---|
689 | default value will be `MULTILIB_OPTIONS', with all slashes treated |
---|
690 | as spaces. |
---|
691 | |
---|
692 | For example, if `MULTILIB_OPTIONS' is specified as `m68000/m68020 |
---|
693 | msoft-float', then the default value of `MULTILIB_DIRNAMES' is |
---|
694 | `m68000 m68020 msoft-float'. You may specify a different value if |
---|
695 | you desire a different set of directory names. |
---|
696 | |
---|
697 | `MULTILIB_MATCHES' |
---|
698 | Sometimes the same option may be written in two different ways. |
---|
699 | If an option is listed in `MULTILIB_OPTIONS', GNU CC needs to know |
---|
700 | about any synonyms. In that case, set `MULTILIB_MATCHES' to a |
---|
701 | list of items of the form `option=option' to describe all relevant |
---|
702 | synonyms. For example, `m68000=mc68000 m68020=mc68020'. |
---|
703 | |
---|
704 | `MULTILIB_EXCEPTIONS' |
---|
705 | Sometimes when there are multiple sets of `MULTILIB_OPTIONS' being |
---|
706 | specified, there are combinations that should not be built. In |
---|
707 | that case, set `MULTILIB_EXCEPTIONS' to be all of the switch |
---|
708 | exceptions in shell case syntax that should not be built. |
---|
709 | |
---|
710 | For example, in the PowerPC embedded ABI support, it was not |
---|
711 | desirable to build libraries that compiled with the |
---|
712 | `-mcall-aixdesc' option and either of the `-mcall-aixdesc' or |
---|
713 | `-mlittle' options at the same time, and therefore |
---|
714 | `MULTILIB_EXCEPTIONS' is set to `*mrelocatable/*mcall-aixdesc* |
---|
715 | *mlittle/*mcall-aixdesc*'. |
---|
716 | |
---|
717 | `MULTILIB_EXTRA_OPTS' |
---|
718 | Sometimes it is desirable that when building multiple versions of |
---|
719 | `libgcc.a' certain options should always be passed on to the |
---|
720 | compiler. In that case, set `MULTILIB_EXTRA_OPTS' to be the list |
---|
721 | of options to be used for all builds. |
---|
722 | |
---|
723 | |
---|
724 | File: gcc.info, Node: Host Fragment, Prev: Target Fragment, Up: Fragments |
---|
725 | |
---|
726 | The Host Makefile Fragment |
---|
727 | ========================== |
---|
728 | |
---|
729 | The host makefile fragment, `x-HOST', defines special host dependent |
---|
730 | variables and targets used in the `Makefile': |
---|
731 | |
---|
732 | `CC' |
---|
733 | The compiler to use when building the first stage. |
---|
734 | |
---|
735 | `CLIB' |
---|
736 | Additional host libraries to link with. |
---|
737 | |
---|
738 | `OLDCC' |
---|
739 | The compiler to use when building `libgcc1.a' for a native |
---|
740 | compilation. |
---|
741 | |
---|
742 | `OLDAR' |
---|
743 | The version of `ar' to use when building `libgcc1.a' for a native |
---|
744 | compilation. |
---|
745 | |
---|
746 | `INSTALL' |
---|
747 | The install program to use. |
---|
748 | |
---|
749 | |
---|
750 | File: gcc.info, Node: Funding, Next: Look and Feel, Prev: Fragments, Up: Top |
---|
751 | |
---|
752 | Funding Free Software |
---|
753 | ********************* |
---|
754 | |
---|
755 | If you want to have more free software a few years from now, it makes |
---|
756 | sense for you to help encourage people to contribute funds for its |
---|
757 | development. The most effective approach known is to encourage |
---|
758 | commercial redistributors to donate. |
---|
759 | |
---|
760 | Users of free software systems can boost the pace of development by |
---|
761 | encouraging for-a-fee distributors to donate part of their selling price |
---|
762 | to free software developers--the Free Software Foundation, and others. |
---|
763 | |
---|
764 | The way to convince distributors to do this is to demand it and |
---|
765 | expect it from them. So when you compare distributors, judge them |
---|
766 | partly by how much they give to free software development. Show |
---|
767 | distributors they must compete to be the one who gives the most. |
---|
768 | |
---|
769 | To make this approach work, you must insist on numbers that you can |
---|
770 | compare, such as, "We will donate ten dollars to the Frobnitz project |
---|
771 | for each disk sold." Don't be satisfied with a vague promise, such as |
---|
772 | "A portion of the profits are donated," since it doesn't give a basis |
---|
773 | for comparison. |
---|
774 | |
---|
775 | Even a precise fraction "of the profits from this disk" is not very |
---|
776 | meaningful, since creative accounting and unrelated business decisions |
---|
777 | can greatly alter what fraction of the sales price counts as profit. |
---|
778 | If the price you pay is $50, ten percent of the profit is probably less |
---|
779 | than a dollar; it might be a few cents, or nothing at all. |
---|
780 | |
---|
781 | Some redistributors do development work themselves. This is useful |
---|
782 | too; but to keep everyone honest, you need to inquire how much they do, |
---|
783 | and what kind. Some kinds of development make much more long-term |
---|
784 | difference than others. For example, maintaining a separate version of |
---|
785 | a program contributes very little; maintaining the standard version of a |
---|
786 | program for the whole community contributes much. Easy new ports |
---|
787 | contribute little, since someone else would surely do them; difficult |
---|
788 | ports such as adding a new CPU to the GNU C compiler contribute more; |
---|
789 | major new features or packages contribute the most. |
---|
790 | |
---|
791 | By establishing the idea that supporting further development is "the |
---|
792 | proper thing to do" when distributing free software for a fee, we can |
---|
793 | assure a steady flow of resources into making more free software. |
---|
794 | |
---|
795 | Copyright (C) 1994 Free Software Foundation, Inc. |
---|
796 | Verbatim copying and redistribution of this section is permitted |
---|
797 | without royalty; alteration is not permitted. |
---|
798 | |
---|
799 | |
---|
800 | File: gcc.info, Node: Look and Feel, Next: Copying, Prev: Funding, Up: Top |
---|
801 | |
---|
802 | Protect Your Freedom--Fight "Look And Feel" |
---|
803 | ******************************************* |
---|
804 | |
---|
805 | This section is a political message from the League for Programming |
---|
806 | Freedom to the users of GNU CC. We have included it here because |
---|
807 | the issue of interface copyright is important to the GNU project. |
---|
808 | |
---|
809 | Apple, Lotus, and now CDC have tried to create a new form of legal |
---|
810 | monopoly: a copyright on a user interface. |
---|
811 | |
---|
812 | An interface is a kind of language--a set of conventions for |
---|
813 | communication between two entities, human or machine. Until a few years |
---|
814 | ago, the law seemed clear: interfaces were outside the domain of |
---|
815 | copyright, so programmers could program freely and implement whatever |
---|
816 | interface the users demanded. Imitating de-facto standard interfaces, |
---|
817 | sometimes with improvements, was standard practice in the computer |
---|
818 | field. These improvements, if accepted by the users, caught on and |
---|
819 | became the norm; in this way, much progress took place. |
---|
820 | |
---|
821 | Computer users, and most software developers, were happy with this |
---|
822 | state of affairs. However, large companies such as Apple and Lotus |
---|
823 | would prefer a different system--one in which they can own interfaces |
---|
824 | and thereby rid themselves of all serious competitors. They hope that |
---|
825 | interface copyright will give them, in effect, monopolies on major |
---|
826 | classes of software. |
---|
827 | |
---|
828 | Other large companies such as IBM and Digital also favor interface |
---|
829 | monopolies, for the same reason: if languages become property, they |
---|
830 | expect to own many de-facto standard languages. But Apple and Lotus are |
---|
831 | the ones who have actually sued. Apple's lawsuit was defeated, for |
---|
832 | reasons only partly related to the general issue of interface copyright. |
---|
833 | |
---|
834 | Lotus won lawsuits against two small companies, which were thus put |
---|
835 | out of business. Then Lotus sued Borland; Lotus won in the trial court |
---|
836 | (no surprise, since it was the same court that had ruled for Lotus twice |
---|
837 | before), but the court of appeals ruled in favor of Borland, which was |
---|
838 | assisted by a friend-of-the-court brief from the League for Programming |
---|
839 | Freedom. |
---|
840 | |
---|
841 | Lotus appealed the case to the Supreme Court, which heard the case |
---|
842 | but was unable to reach a decision. This failure means that the appeals |
---|
843 | court decision stands, in one portion of the United States, and may |
---|
844 | influence the other appeals courts, but it does not set a nationwide |
---|
845 | precedent. The battle is not over, and it is not limited to the United |
---|
846 | States. |
---|
847 | |
---|
848 | The battle is extending into other areas of software as well. In |
---|
849 | 1995 a company that produced a simulator for a CDC computer was shut |
---|
850 | down by a copyright lawsuit, in which CDC charged that the simulator |
---|
851 | infringed the copyright on the manuals for the computer. |
---|
852 | |
---|
853 | If the monopolists get their way, they will hobble the software |
---|
854 | field: |
---|
855 | |
---|
856 | * Gratuitous incompatibilities will burden users. Imagine if each |
---|
857 | car manufacturer had to design a different way to start, stop, and |
---|
858 | steer a car. |
---|
859 | |
---|
860 | * Users will be "locked in" to whichever interface they learn; then |
---|
861 | they will be prisoners of one supplier, who will charge a |
---|
862 | monopolistic price. |
---|
863 | |
---|
864 | * Large companies have an unfair advantage wherever lawsuits become |
---|
865 | commonplace. Since they can afford to sue, they can intimidate |
---|
866 | smaller developers with threats even when they don't really have a |
---|
867 | case. |
---|
868 | |
---|
869 | * Interface improvements will come slower, since incremental |
---|
870 | evolution through creative partial imitation will no longer occur. |
---|
871 | |
---|
872 | If interface monopolies are accepted, other large companies are |
---|
873 | waiting to grab theirs: |
---|
874 | |
---|
875 | * Adobe is expected to claim a monopoly on the interfaces of various |
---|
876 | popular application programs, if Lotus ultimately wins the case |
---|
877 | against Borland. |
---|
878 | |
---|
879 | * Open Computing magazine reported a Microsoft vice president as |
---|
880 | threatening to sue people who imitate the interface of Windows. |
---|
881 | |
---|
882 | Users invest a great deal of time and money in learning to use |
---|
883 | computer interfaces. Far more, in fact, than software developers |
---|
884 | invest in developing *and even implementing* the interfaces. Whoever |
---|
885 | can own an interface, has made its users into captives, and |
---|
886 | misappropriated their investment. |
---|
887 | |
---|
888 | To protect our freedom from monopolies like these, a group of |
---|
889 | programmers and users have formed a grass-roots political organization, |
---|
890 | the League for Programming Freedom. |
---|
891 | |
---|
892 | The purpose of the League is to oppose monopolistic practices such as |
---|
893 | interface copyright and software patents. The League calls for a return |
---|
894 | to the legal policies of the recent past, in which programmers could |
---|
895 | program freely. The League is not concerned with free software as an |
---|
896 | issue, and is not affiliated with the Free Software Foundation. |
---|
897 | |
---|
898 | The League's activities include publicizing the issues, as is being |
---|
899 | done here, and filing friend-of-the-court briefs on behalf of |
---|
900 | defendants sued by monopolists. |
---|
901 | |
---|
902 | The League's membership rolls include Donald Knuth, the foremost |
---|
903 | authority on algorithms, John McCarthy, inventor of Lisp, Marvin Minsky, |
---|
904 | founder of the MIT Artificial Intelligence lab, Guy L. Steele, Jr., |
---|
905 | author of well-known books on Lisp and C, as well as Richard Stallman, |
---|
906 | the developer of GNU CC. Please join and add your name to the list. |
---|
907 | Membership dues in the League are $42 per year for programmers, managers |
---|
908 | and professionals; $10.50 for students; $21 for others. |
---|
909 | |
---|
910 | Activist members are especially important, but members who have no |
---|
911 | time to give are also important. Surveys at major ACM conferences have |
---|
912 | indicated a vast majority of attendees agree with the League on both |
---|
913 | issues (interface copyrights and software patents). If just ten percent |
---|
914 | of the programmers who agree with the League join the League, we will |
---|
915 | probably triumph. |
---|
916 | |
---|
917 | To join, or for more information, send electronic mail to the |
---|
918 | address `lpf@uunet.uu.net' or write to: |
---|
919 | |
---|
920 | League for Programming Freedom |
---|
921 | 1 Kendall Square #143 |
---|
922 | P.O. Box 9171 |
---|
923 | Cambridge, MA 02139 |
---|
924 | |
---|
925 | In addition to joining the League, here are some suggestions from the |
---|
926 | League for other things you can do to protect your freedom to write |
---|
927 | programs: |
---|
928 | |
---|
929 | * Tell your friends and colleagues about this issue and how it |
---|
930 | threatens to ruin the computer industry. |
---|
931 | |
---|
932 | * Mention that you are a League member in your `.signature', and |
---|
933 | mention the League's email address for inquiries. |
---|
934 | |
---|
935 | * Ask the companies you consider working for or working with to make |
---|
936 | statements against software monopolies, and give preference to |
---|
937 | those that do. |
---|
938 | |
---|
939 | * When employers ask you to sign contracts giving them copyright on |
---|
940 | your work, insist on a clause saying they will not claim the |
---|
941 | copyright covers imitating the interface. |
---|
942 | |
---|
943 | * When employers ask you to sign contracts giving them patent rights, |
---|
944 | insist on clauses saying they can use these rights only |
---|
945 | defensively. Don't rely on "company policy," since that can |
---|
946 | change at any time; don't rely on an individual executive's |
---|
947 | private word, since that person may be replaced. Get a commitment |
---|
948 | just as binding as the commitment they get from you. |
---|
949 | |
---|
950 | * Write to Congress to explain the importance of these issues. |
---|
951 | |
---|
952 | House Subcommittee on Intellectual Property |
---|
953 | 2137 Rayburn Bldg |
---|
954 | Washington, DC 20515 |
---|
955 | |
---|
956 | Senate Subcommittee on Patents, Trademarks and Copyrights |
---|
957 | United States Senate |
---|
958 | Washington, DC 20510 |
---|
959 | |
---|
960 | (These committees have received lots of mail already; let's give |
---|
961 | them even more.) |
---|
962 | |
---|
963 | Democracy means nothing if you don't use it. Stand up and be |
---|
964 | counted! |
---|
965 | |
---|