Drivers
-
Thank you guys. I’m going to stop bugging you with my questions, at least for now.
Calin Negru wrote:
I’m going to stop bugging you with my questions, at least for now.
Don't worry! It is nice having someone to ask questions so that the responder is forced to straighten out things in his head, in a way to make it understandable. As long as you can handle somewhat lengthy answers, it is OK with me! :-) When you get around to ask questions about networking, there is a risk that I might provide even longer and a lot more emotional answers. I am spending time nowadays to straighten out why the Intranet Protocol has p**ed me off for 30+ years! When I do that kind of things, I often do it in the form of a lecturer or presenter who tries to explain ideas or principles, and must answer to questions and objections from the the audience. So I must both get the ideas and principles right, and the objections and 'smart' questions. That is really stimulating - trying to understand the good arguments for why IP, say, was created the way it was. (It has been said that Albert Einstein, when as a university professor got into some discussion with graduate students, and of course won it, sometimes told the defeated student: OK, now you take my position to defend, and I will take yours! ... and again, Einstein won the discussion. If is isn't true, it sure is a good lie!)
Religious freedom is the freedom to say that two plus two make five.
-
Calin Negru wrote:
Is a machine instruction a 32 bit word/variable?
This is something I have been fighting since my student days! :-) What resides in a computer isn't "really" numbers. Or characters. Or instructions. Saying that an alphabetic character "really is stored as a number inside the machine" is plain BS! RAM, register and whatever else holds bit patterns, period. Not even zeroes and ones, in any numeric sense. It is charged/uncharged. High/low voltage. High/low current. On/off. Not numbers. When a stream of bits comes out of machine, we may have a convention for presenting e.g. a given sequence of bits as the character 'A'. That is a matter of presentation. Alternately, we may present it as the decimal number 49. This is no more a "true" presentation than 'A'. Or a dark grey dot in a monochrome raster image. If we have agreed upon the semantics of a given byte as an 'A', claiming anything else is simply wrong. The only valid alternative is to treat the byte as an uninterpreted bit string. And that is not as a sequence of numeric 0 and 1, which is an (incorrect) interpretation. A CPU may interpret a bit sequence as an instruction. Presumably, this is also the semantics intended by the compiler generating the bit sequence. The semantics is that of, say, the ALU adding two registers - the operation itself, not a description of it. You may (rightfully) say: "But I cannot do that operation when I read the code". So for readability reasons, we make an (incorrect) presentation, grouping bits by 4 and showing as hexadecimal digits. We may go further, interpreting a number of bits as an index into a string table where we find the name of the operation. This doesn't change the bit sequence into a printable string; it remains a bit pattern, intended for the CPU's interpretation as a set of operations. So it all is bit patterns. If we feed the bit patters to a printer, we assume that the printer will interpret them as characters; hopefully that is correct. If we feed bit patterns to the CPU, we assume that it will interpret them as instructions. Usually, we keep those bit patterns that we intend to be interpreted as instructions by a CPU separate from those bit patterns we intend to be interpreted as characters, integer or real numbers, sound or images. That is mostly a matter of orderliness. And we cannot always keep a watertight bulkhead between those bit patterns intended for text o
>This is something I have been fighting I know it’s an important problem. If you don’t understand that it’s like having a car which has doors that don’t close properly.