1 |
Peter Humphrey posted <43F20CE2.9090503@××××××××××.uk>, excerpted below, |
2 |
on Tue, 14 Feb 2006 17:01:22 +0000: |
3 |
|
4 |
> Duncan wrote: |
5 |
>> John Myers posted <200602081850.05729.electronerd@×××××××××××××.net>, |
6 |
>> excerpted below, on Wed, 08 Feb 2006 18:49:54 -0800: |
7 |
>> |
8 |
>>> x86_64 does not require frame pointers for debugging, so |
9 |
>>> -fomit-frame-pointer is enabled with -O |
10 |
>> |
11 |
>> /Click/. THAT'S the reason I hadn't removed the potentially redundant |
12 |
>> -fomit-frame-pointer! I'd forgotten about that, but the manpage /does/ |
13 |
>> mention that it's only enabled with -O<whatever> where it won't interfere |
14 |
>> with debugging, and I was unsure of whether that was the case on |
15 |
>> x86_64/amd64 or not, so I left it in. Knowing that it doesn't interfere |
16 |
>> with debugging on amd64, and is therefore enabled by -O<whatever>, I could |
17 |
>> probably remove the redundancy, now. |
18 |
> |
19 |
> I'm having trouble with this "enable" word. To me it means to make able, or |
20 |
> to make possible, in the manner of opening a gate; but I often get the |
21 |
> distinct impression that it's being used forcefully, in the manner of being |
22 |
> pushed through the gate. /etc/init.d/numlock is a case in point - it says |
23 |
> it's enabled numlock when in fact it's set it. |
24 |
> |
25 |
> So if the man page says that "it's only enabled with -O<whatever>" I infer |
26 |
> that it has no effect in the absence of -O? and therefore need only be |
27 |
> specified if -O? is present. Is that what you two mean? I suspect you mean |
28 |
> 'forced' rather than 'enabled'. |
29 |
> |
30 |
> I don't mean to appear pedantic, but I need help here :-( |
31 |
|
32 |
I hadn't thought of things from that particular viewpoint, before. |
33 |
|
34 |
You have a point, as the term is used in regular English. However, the |
35 |
term has a slightly different twist when used in reference to computers by |
36 |
computer literate users. |
37 |
|
38 |
The history of the term "enable" in computer usage, I believe traces to |
39 |
its use for computer hardware. Consider the old serial protocols as used |
40 |
in telephone modems and the like. Being binary logic, each signal line |
41 |
had two states, 0/off, typically at ground-reference voltage, and 1/on, |
42 |
typically at 5 volt reference relative to ground. The following |
43 |
description should be generally accurate, altho I never mapped the |
44 |
specifics for any particular protocol or pin-out into |
45 |
permanent brain-memory, only absorbing enough to understand the principles |
46 |
of how it worked. |
47 |
|
48 |
There were a number of such signal lines, including the data line and |
49 |
several control lines that signaled status of various components at each |
50 |
end. When one end or the other had processed its current buffer of data |
51 |
and was ready to receive more, it would "enable" or raise the appropriate |
52 |
signal line, toggling it on (that is, to 5v reference), saying in effect |
53 |
"I'm ready to recieve more data." When data came and its buffer got full, |
54 |
it would disable/lower the appropriate signal line, saying in effect "OK, |
55 |
I've got all the data I can handle right now, stop, while I process it." |
56 |
Similarly, there other lines for transmit, where a hi status meant "Hey, I |
57 |
have data available to transmit, tell me when you are ready to receive it." |
58 |
|
59 |
BTW, the old parallel protocol worked similarly, only instead of a single |
60 |
data line, it had eight (or was it 16?), so it could transmit an entire |
61 |
byte (2?) in the same time it took a serial line to transmit a single bit. |
62 |
What's interesting today is to observe that as time progressed and signal |
63 |
speeds increased, shielding became more and more important, such that |
64 |
today, it's technically easier to send data down a single very well |
65 |
shielded serial data line at more than eight times the speed, as opposed |
66 |
to trying to shield eight (or 16 or 32 or 64 or...) data lines well enough |
67 |
to reliably transport the data at the appropriate fraction of the speed! |
68 |
That's one reason SATA is faster than PATA, tho PATA has multiple data |
69 |
lines while SATA has only one, and why both USB and IEEE1394 aka Firewire |
70 |
are both serial protocols. |
71 |
|
72 |
Anyway, if you look at the pinouts of those old serial specs, or remember |
73 |
the best old analog modems, which had LED indicators for all of the status |
74 |
lines, you'll find labels such as DTR (Data Terminal Ready) and CTS (Clear |
75 |
To Send) for the various status lines. A hi or enabled status, a glowing |
76 |
LED, meant that the modem or computer was ready to take the corresponding |
77 |
action. should the other end respond in the expected way. A lo or |
78 |
disabled status meant it wasn't ready, so any data coming down the data |
79 |
line at that point meant sure trouble, as it would be lost. |
80 |
|
81 |
Thus, at that point, "enabled" (as an adjective) meant much the same as it |
82 |
does in regular English -- it "enabled" whatever action to occur, tho it |
83 |
didn't necessarily mean it /would/ occur, if the other end didn't have any |
84 |
data to send at the moment. |
85 |
|
86 |
However, from that, since "enabled" always meant the corresponding line |
87 |
was on or hi, it was a logical and relatively quick evolution to the point |
88 |
where "enable" used as a verb came to mean "toggle-on" -- the two became |
89 |
synonymous, in computer usage. |
90 |
|
91 |
Fast-forward to the present day, and you see this usage in the above |
92 |
discussion of gcc flags and in your example, "enabling" the numlock. |
93 |
However, there's still an element of the original and standard English |
94 |
usage, if you think about it. Just because numlock is "enabled" doesn't |
95 |
mean there WILL be signals coming from the keyboard on the associated |
96 |
keys. It only means that if they come, a specific interpretation of them |
97 |
has been "enabled". Like the old serial protocol, if DTR was "enabled" it |
98 |
meant any data sent would be interpreted in a specific way. If it was |
99 |
disabled and the same data was sent, it would be interpreted differently, |
100 |
in the case of the protocol, causing data to be thrown out and lost. |
101 |
|
102 |
Similarly with gcc, just because a specific optimization is "enabled" |
103 |
doesn't mean that any code will actually USE that optimization. It only |
104 |
means that should the opportunity to use the optimization arise, taking |
105 |
advantage of it is "enabled", where if the optimization were "disabled" |
106 |
the code that /could/ have taken advantage of that optimization won't. |
107 |
|
108 |
That should make things considerably clearer. -O<whatever> "enabling" a |
109 |
particular optimization simply means that it's turned on, same as if you'd |
110 |
"enabled" that particular optimization individually. However, regardless |
111 |
of how that optimization is "enabled", just because it /is/ "enabled" |
112 |
doesn't mean any code will come along that actually can make use of that |
113 |
optimization, so the original English meaning of the term "enable" is |
114 |
retained in that sense. |
115 |
|
116 |
... |
117 |
|
118 |
My Dad is a teacher. He has often stated that the best way to /learn/ |
119 |
something is to attempt to teach it. Here, we see that demonstrated in |
120 |
action, as well as why that's the case. The particular viewpoint that |
121 |
caused the question to be asked had never occurred to me. Had the |
122 |
question not been asked, I would therefore have never examined the details |
123 |
of "enable" and its precise meaning in the computer context. Because |
124 |
someone asked the question, and in an effort to explain the answer, I was |
125 |
forced to reexamine my own assumptions about "enable", gaining a keener |
126 |
understanding of the term and its appropriate usage in the process. Once |
127 |
again, the teacher ends up learning far more about a subject he's trying |
128 |
to teach than he would have otherwise known! My Dad and his saying has |
129 |
been demonstrated correct, once again! =8^) |
130 |
|
131 |
So... Thanks very much for asking the question! I learned a lot in |
132 |
formulating an answer to it that I would have never become aware of, |
133 |
otherwise! =8^) |
134 |
|
135 |
-- |
136 |
Duncan - List replies preferred. No HTML msgs. |
137 |
"Every nonfree program has a lord, a master -- |
138 |
and if you use the program, he is your master." Richard Stallman in |
139 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
140 |
|
141 |
|
142 |
-- |
143 |
gentoo-amd64@g.o mailing list |