[gentoo-amd64] Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite

[Duncan]

Peter Humphrey posted <43F20CE2.9090503@××××××××××.uk>, excerpted below, 
on Tue, 14 Feb 2006 17:01:22 +0000:

> Duncan wrote:
>> John Myers posted <200602081850.05729.electronerd@×××××××××××××.net>,
>> excerpted below,  on Wed, 08 Feb 2006 18:49:54 -0800:
>>
>>> x86_64 does not require frame pointers for debugging, so
>>> -fomit-frame-pointer is enabled with -O
>>
>> /Click/.  THAT'S the reason I hadn't removed the potentially redundant
>> -fomit-frame-pointer!  I'd forgotten about that, but the manpage /does/
>> mention that it's only enabled with -O<whatever> where it won't interfere
>> with debugging, and I was unsure of whether that was the case on
>> x86_64/amd64 or not, so I left it in.  Knowing that it doesn't interfere
>> with debugging on amd64, and is therefore enabled by -O<whatever>, I could
>> probably remove the redundancy, now.
>
> I'm having trouble with this "enable" word. To me it means to make able, or
> to make possible, in the manner of opening a gate; but I often get the
> distinct impression that it's being used forcefully, in the manner of being
> pushed through the gate. /etc/init.d/numlock is a case in point - it says
> it's enabled numlock when in fact it's set it.
>
> So if the man page says that "it's only enabled with -O<whatever>" I infer
> that it has no effect in the absence of -O? and therefore need only be
> specified  if -O? is present. Is that what you two mean? I suspect you mean
> 'forced' rather than 'enabled'.
>
> I don't mean to appear pedantic, but I need help here :-(

I hadn't thought of things from that particular viewpoint, before.

You have a point, as the term is used in regular English.  However, the
term has a slightly different twist when used in reference to computers by
computer literate users.

The history of the term "enable" in computer usage, I believe traces to
its use for computer hardware.  Consider the old serial protocols as used
in telephone modems and the like.  Being binary logic, each signal line
had two states, 0/off, typically at ground-reference voltage, and 1/on,
typically at 5 volt reference relative to ground.  The following
description should be generally accurate, altho I never mapped the
specifics for any particular protocol or pin-out into
permanent brain-memory, only absorbing enough to understand the principles
of how it worked.

There were a number of such signal lines, including the data line and
several control lines that signaled status of various components at each
end.  When one end or the other had processed its current buffer of data
and was ready to receive more, it would "enable" or raise the appropriate
signal line, toggling it on (that is, to 5v reference), saying in effect
"I'm ready to recieve more data."  When data came and its buffer got full,
it would disable/lower the appropriate signal line, saying in effect "OK,
I've got all the data I can handle right now, stop, while I process it." 
Similarly, there other lines for transmit, where a hi status meant "Hey, I
have data available to transmit, tell me when you are ready to receive it."

BTW, the old parallel protocol worked similarly, only instead of a single
data line, it had eight (or was it 16?), so it could transmit an entire
byte (2?) in the same time it took a serial line to transmit a single bit.
What's interesting today is to observe that as time progressed and signal
speeds increased, shielding became more and more important, such that
today, it's technically easier to send data down a single very well
shielded serial data line at more than eight times the speed, as opposed
to trying to shield eight (or 16 or 32 or 64 or...) data lines well enough
to reliably transport the data at the appropriate fraction of the speed!
That's one reason SATA is faster than PATA, tho PATA has multiple data
lines while SATA has only one, and why both USB and IEEE1394 aka Firewire
are both serial protocols.

Anyway, if you look at the pinouts of those old serial specs, or remember
the best old analog modems, which had LED indicators for all of the status
lines, you'll find labels such as DTR (Data Terminal Ready) and CTS (Clear
To Send) for the various status lines.  A hi or enabled status, a glowing
LED, meant that the modem or computer was ready to take the corresponding
action. should the other end respond in the expected way.  A lo or
disabled status meant it wasn't ready, so any data coming down the data
line at that point meant sure trouble, as it would be lost.

Thus, at that point, "enabled" (as an adjective) meant much the same as it
does in regular English -- it "enabled" whatever action to occur, tho it
didn't necessarily mean it /would/ occur, if the other end didn't have any
data to send at the moment.

However, from that, since "enabled" always meant the corresponding line
was on or hi, it was a logical and relatively quick evolution to the point
where "enable" used as a verb came to mean "toggle-on" -- the two became
synonymous, in computer usage.  

Fast-forward to the present day, and you see this usage in the above
discussion of gcc flags and in your example, "enabling" the numlock. 
However, there's still an element of the original and standard English
usage, if you think about it.  Just because numlock is "enabled" doesn't
mean there WILL be signals coming from the keyboard on the associated
keys.  It only means that if they come, a specific interpretation of them
has been "enabled".  Like the old serial protocol, if DTR was "enabled" it
meant any data sent would be interpreted in a specific way.  If it was
disabled and the same data was sent, it would be interpreted differently,
in the case of the protocol, causing data to be thrown out and lost.

Similarly with gcc, just because a specific optimization is "enabled"
doesn't mean that any code will actually USE that optimization.  It only
means that should the opportunity to use the optimization arise, taking
advantage of it is "enabled", where if the optimization were "disabled"
the code that /could/ have taken advantage of that optimization won't.

That should make things considerably clearer.  -O<whatever> "enabling" a
particular optimization simply means that it's turned on, same as if you'd
"enabled" that particular optimization individually.  However, regardless
of how that optimization is "enabled", just because it /is/ "enabled"
doesn't mean any code will come along that actually can make use of that
optimization, so the original English meaning of the term "enable" is
retained in that sense.

...

My Dad is a teacher.  He has often stated that the best way to /learn/
something is to attempt to teach it.  Here, we see that demonstrated in
action, as well as why that's the case.  The particular viewpoint that
caused the question to be asked had never occurred to me.  Had the
question not been asked, I would therefore have never examined the details
of "enable" and its precise meaning in the computer context.  Because
someone asked the question, and in an effort to explain the answer, I was
forced to reexamine my own assumptions about "enable", gaining a keener
understanding of the term and its appropriate usage in the process.  Once
again, the teacher ends up learning far more about a subject he's trying
to teach than he would have otherwise known!  My Dad and his saying has
been demonstrated correct, once again! =8^)

So... Thanks very much for asking the question!  I learned a lot in
formulating an answer to it that I would have never become aware of,
otherwise! =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list