From owner-freebsd-chat@FreeBSD.ORG Sun Jun 24 07:31:51 2007 Return-Path: X-Original-To: freebsd-chat@FreeBSD.ORG Delivered-To: freebsd-chat@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFF8B16A41F for ; Sun, 24 Jun 2007 07:31:51 +0000 (UTC) (envelope-from mjalvarez@fastmail.fm) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id B281913C45D for ; Sun, 24 Jun 2007 07:31:51 +0000 (UTC) (envelope-from mjalvarez@fastmail.fm) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 7EAB71CBC for ; Sun, 24 Jun 2007 03:31:50 -0400 (EDT) Received: from web6.messagingengine.com ([10.202.2.215]) by compute1.internal (MEProxy); Sun, 24 Jun 2007 03:31:50 -0400 Received: by web6.messagingengine.com (Postfix, from userid 99) id 557FF6D2A; Sun, 24 Jun 2007 03:31:50 -0400 (EDT) Message-Id: <1182670310.32703.1196739027@webmail.messagingengine.com> X-Sasl-Enc: NNwYZdmBOVJDHnuLwePhMCyiyAjrz32wboVAQ369RJQw 1182670310 From: "Mark Jayson Alvarez" To: freebsd-chat@FreeBSD.ORG, mjalvarez@fastmail.fm Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface References: <200706211633.l5LGXWvG095148@lurza.secnetix.de> In-Reply-To: <200706211633.l5LGXWvG095148@lurza.secnetix.de> Date: Sun, 24 Jun 2007 15:31:50 +0800 Cc: Subject: Re: Where software meets hardware.. (Hello World program dissected) X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2007 07:31:52 -0000 Hi, To fully understand things, here's another scenario. A "Hello World" program. This time I'm going to dissect all the processes, as far as I can. Upon boot up, electric charge fills some capacitors in=20 the memory in a certain pattern of "charged and not charged" (1 and 0). The pattern that was formed points into "another some capacitors" or addresses in the memory. This pattern of "charged and not charged" capacitors is called the "Interrupt Handler Table". "Another some capacitors" are the actual "Interrupt Handlers" Back to the "Hello World" program. Before anything else, first when the computer boots up, the operating system is loaded into the memory. The operating system also loads the driver for every device it finds in=20 the computer. All of these are in the form of charged and not charged capacitor patterns. "Hello World" program continued... First, I pressed a series of keys in my keyboard then electronic current flows into the keyboard port attached to the motherboard. Then this port has a circuit connected to a particular pin in the CPU. Then the CPU upon getting interrupted by the electronic current that has arrived into this particular pin, through some sort of transistors/capacitor magic, accesses the "Interrupt Handler Table" in the memory and look up the address that points into the actual "Interrupt Handler" for the keyboard. Now that "Interrupt Handler" is also a pattern of "Charged and not charged" capacitors which represents a binary driver written to the memory=20 by the operating system upon bootup.=20 The processor does all its machine codes stuffs to dissect and process this keyboard driver via an Operating System routine, store the result first into its register and then write it back to the RAM, return the execution and=20 the results back to the operating system routine that called the driver. Now the operating system knows that I have actually pressed some keys in=20 the keyboard and do the same processes to echoed everything that I have typed into the monitor and also write it on the surface of my hard=20 drive using magnetism. Everthing that I have typed, echoed into the monitor, and got written into the surface of my hard drive looks like: #include main() { for(;;) {=20 printf ("Hello World!\n"); } } Now I run the compiler, read the above series of characters which are written on the surface of my hard drive as pattern of 1's and 0's or "magnetized and not magnetized =3D)" and write everything back into a binary format or a pattern of 1's and 0's, again?? The process of actually executing the routine in the Operating system that writes these binary code into the memory for the processor to process and run it, is actually running the program itself. Things are more clearer now. It's all about electric charges, either "on" or "off". The most essential parts are the processor and the memory. The processor do all the processing using some sort of transistors and capacitors magic. Everything that gets processed are written by the processor into the memory in a form of=20 electronically charged and not charged capacitors. The only confusing thing that is left is that binary format thing. I thought everything that is written in the hard drive is already a series of 1's and 0's. If I compile the program, it is converted into a machine readable format or a binary format.=20 What's the physical difference of binary and non binary format?? The only difference I can see is that when I open the non binary format in an editor, it is quite readable unlike the binary format which is full of mixed and unrecognizable characters. Thanks for the time. -jay On Thu, 21 Jun 2007 18:33:32 +0200 (CEST), "Oliver Fromme" said: > Mark Jayson Alvarez wrote: > > Let's say I have a very simple washing machine program. > > Now it has a timer which the duration of the spinning can be set. > > If I press the 3-minute button, wires beneath will get shorted. > > Electric current will flow into pin number 5 of the parallel cable > > connected to the parallel port of my PC. Now the CPU has a pin > > connected to this port. If it receives let's say 5V, it will stop > > what it's doing and=20 > >=20 > > > fetches the > > > address of an "interrupt handler routine" from memory, > > > and jumps to that address (i.e. starts executing > > > instructions from that address). That handler is > > > usually installed in memory by the operating system. > > > The code checks which device caused the interrupt, > > > and then executes the appropriate routine in the > > > corresponding device driver. > >=20 > > And when exactly did the Operating system installed this interrupt > > handler?? >=20 > When it boots. The processor supports an interrupt > handler address table. That's simply a list of memory > addresses which is itself stored in memory. Each > kind of interrupt (they're numbered) has an entry > in that table that points to the appropriate interrupt > handler which has been installed by the OS upon boot. >=20 > For example, let's say interrupt line 7 is connected > to the parallel port. So when the processer receives > a signal on that line, it looks up the address that > is stored in entry #7 in the interrupt table. Then > it will execute commands at that memory address, and > afterwards it will resume whatever was interupted. >=20 > > And suppose this handler runs the driver and the=20 > > appropriate routine inside it, how did the driver able to convert the > > electric > > current into a machine understandable data and was able to pass it > > to a program and the program receive the data as 3 minutes? >=20 > It depends. If you have one interrupt per button, > then there's a one-to-one relation ship between > buttons and interrupt numbers. So if you press > that 3-minutes-button, let's say it's connected to > interrupt pin #7, so the processor will run the > handler that has been registered for interrupt #7. > That handler is specific to that interrupt and to > that button, so it "knows" that the 3-minutes-button > has been pressed when it is called (because that's > why it was installed for the interrupt in the first > place). There is no need for the driver to "convert > the electric current". The handler is called as a > reaction to the interrupt signal, and that reaction > in itself contains the information about the press > of the button. >=20 > However -- normally you don't have one interrupt > per button, but rather one interrupt per device. > Having one interrupt per key (on a keyboard) would > be very inefficient. Instead, there is one interrupt > for the whole keyboard (or for all the buttons on a > device). So, any button press will cause the same > handler to be executed. The device driver routine > knows that a button has been pressed, but it still > has to find out which one. How does it do that? >=20 > Well, in simple cases (like embedded systems in a > washing machine), the electrical lines from the > buttons are connected to I/O pins on the processor, > or on separate I/O chip which is connected to the > actual processor. Basically this is similar to an > interrupt line, in that it causes a pin to go from > 0 V to 5 V (or whatever voltage levels are used). > But the difference is that it does not cause an > interrupt to occur. The processor simply ignores > those I/O pins during normal operation. However, > the processor supports machine codes that can read > the current state of the I/O pins. If the processor > executes such a code (i.e. a certain byte sequence), > it copies the current state of the I/O pins into a > register, where it can be dissected and examined > with other machine instructions. That state is > usually encoded in a binary format, where each bit > corresponds to one I/O pin. A single byte has 8 bit, > so it can contain the information of 8 such I/O pins. > If a pin is 0 V, the corresponding bit is 0, > otherwise it is 1. >=20 > > Driver is just a software right? >=20 > Right. >=20 > > I'm sure if I can find out how electric current have been actually > > converted into 1's and 0's I will not have trouble understanding > > how it can be converted the other way around. >=20 > Actually nothing needs to be converted. "0" and "1" > are just interpretations of different voltage levels. >=20 > > It has something to do with registers right? What are this > > registers looks like? A microchip that can get written using > > electric current? >=20 > Processor register are simply small pieces of memory > inside the processor. They are required for the > processor to perform calculations and other things, > because they cannot be performed directly in RAM. > In order to do anything with data stored in RAM, the > processor has to load values into registers, and > when it's done, the result have to be stored back > into RAM. >=20 > For example, in order to add two numbers that are > stored in memory, the processor loads both of them > into two of its registers. Once they're there, they > are added by the ALU (=3D=3D arithmetic-logial unit, > part of the processor), and the result is again > stored in a register. Then the contents of that > register are written back to main memory. >=20 > > What are these 1's and 0's look like anyway? How are they written in t= he > > memory? A chemical reaction when electric current flows into the ram? >=20 > No, it's all electrophysical, not chemical. Well, a > "1" usually looks like 0 V, and a "1" looks like 5V > (or 3 V or whatever). Inside electronic components > such as processors, RAM, graphics and network cards > etc., bits are almost always represented as voltage > levels. >=20 > > Data that is written in the RAM differs the way they are written in a > > hard drive or a CD right? But the truth is they are all 1's and 0's? >=20 > Yes. All media (RAM, flash, disks, tapes, CD, DVD > and even punch cards) have in common that they store > data as "0" or "1" in one form or another. The > important property is that the media is capable of > having two distinct states, so one of the states is > assigned the "0" value and the other the "1" value. >=20 > For example, CDs have tiny "pits" on the surface. > A laser beam measures the width of those pits (small > ones and large ones), and a DSP converts that into a > sequence of "0" and "1". >=20 > On hard disks the same information is stored using > magnetism. RAM (DRAM =3D=3D dynamic RAM) uses tiny > capacitors to hold a very small electric charge that > represents the bit value. >=20 > If you want to know more details about how a processor > access data in memory, how address bus and data bus > works, how a processor is built up from transistor > functions, I strongly recommend that you buy a good > beginners book of processor design. >=20 > I remember at school we've built simple electronic > components ourselves: a flipflop (that's a simple > 1-bit memory) from two transistors, logical gates > (i.e. "and", "or", "not" circuits), bit counters, > adders and similar things. At that time that was > very enlightening for me. I suggest you try > something like that, too. You can buy electronic > construction and experimentation kits at toy shops. > Don't be afraid that they're intended for children, > I know quite some adults who play with things like > that once in a while, including myself. :-) >=20 > Best regards > Oliver >=20 > --=20 > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch=E4ftsfuehrun= g: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M=FC= n- > chen, HRB 125758, Gesch=E4ftsf=FChrer: Maik Bachmann, Olaf Erb, Ralf Geb= hart >=20 > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd >=20 > "C++ is the only current language making COBOL look good." > -- Bertrand Meyer --=20 Mark Jayson Alvarez mjalvarez@fastmail.fm --=20 http://www.fastmail.fm - Choose from over 50 domains or use your own