Date: Thu, 21 Jun 2007 22:15:56 +0800 From: "Mark Jayson Alvarez" <mjalvarez@fastmail.fm> To: freebsd-chat@FreeBSD.ORG, mjalvarez@fastmail.fm Subject: Re: Where software meets hardware.. Message-ID: <1182435356.26688.1196346301@webmail.messagingengine.com> In-Reply-To: <200706211233.l5LCXuYv082845@lurza.secnetix.de> References: <200706211233.l5LCXuYv082845@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, 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 > 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. And when exactly did the Operating system installed this interrupt handler?? 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? Driver is just a software right? This part is what really confuses me.=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. It has something to do with registers right? What are this registers looks like? A microchip that can get written using electric current? What are these 1's and 0's look like anyway? How are they written in the memory? A chemical reaction when electric current flows into the ram? 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? Thanks you very much! Sincerely, jay On Thu, 21 Jun 2007 14:33:56 +0200 (CEST), "Oliver Fromme" <olli@lurza.secnetix.de> said: > Mark Jayson Alvarez wrote: > > Good day! I could have sent this to questions@freebsd.org but I know > > it will get treated as irrelevant topic as well. Just trying my luck > > here though. >=20 > Actually this is most appropriate on the "chat" list. > I've redirected replies there. >=20 > > I have a cousin who's taking up a programming course. He doesn't have > > background with programming nor an in depth understanding of how the > > computer works. I tried explaining him that it all started with > > abacus, and that people wanted to use something that could make their > > arithmetic life easier and that Charles Babbage tried automating this > > manual calculator with his steam engine or some sort... and that... >=20 > Actually Charles Babbage designed a complex mechanical > computing machine (with lots of gearwheels etc.), but > it only ever existed on paper. Only small parts of it > have actually been built, but never the whole thing, > because it was too complex. It would work in theory, > though. :-) >=20 > > This is how my programming teacher explains how a program gets > > executed. First you compile it into a machine readable code, then > > the operating system writes it in the memory, and finally the CPU > > fetches it and it finally gets toasted by the electricity flowing on > > the CPU's surface. It doesn't make things clearer though.:-( >=20 > That's pretty close to the truth, actually. >=20 > > I really don't get it. Can you in a very simple sentence explain to > > me how and where a software program >=20 > I'm afraid the interactions between memory, processor > (CPU) and software is a complex thing which cannot be > explained in a single simple sentence. I'll try to > explain a bit ... >=20 > A processor is able to execute instructions which are > called "machine code". Basically it's a sequence of > bytes stored in memory (RAM). The processor fetches > byte after byte from memory and executes the commands > that they represent. Such commands include: "load > a number from memory into a processor register", or > "add these two processor registers and store the result > in memory", or "check whether this value is zero, and > if it is, then jump to a specified address in memory > instead of continuing with the following instruction". > It's possible to have loops, subroutines, interrupt > routines and other things, but the details aren't > important in order to get a basic understanding. >=20 > Of course, most programmers don't write that machine > code directly. It's efficient for the processor to > execute, but it's inconvenient for a human programmer > to write. A programmer usually writes programs in a > higher-level language, such as C. Then a tool called > compiler is used to convert that "source code" into > "machine code" that can be executed by the processor. > The result is an executable file stored on disk (also > called a "binary"). >=20 > When a binary is about to be executed, the operating > system (such as FreeBSD) loads it from disk into RAM > where its byte stream can be executed by the processor. >=20 > Of course in reality it's more complicated, but the > above are the very basic and low-level things that > happen. >=20 > Device drivers are somewhat different. They're normal > binaries, too (usually compiled from source code, too), > but they're loaded once when the operating system boots > the computer, or once when the appropriate kernel > module is loaded. Many device drivers are interrupt- > driven. When an external event occurs, such as a > packet arriving on a network interface, or the user > pressing a key on the keyboard, the hardware device > signals an interrupt to the processor (basically a > connector pin on the processor is set from "low" to > "high", i.e. from 0 V to 5 V or similar). The processor > stops whatever it is doing right now, 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. When it's finished, > a "return" instruction is executed, which causes the > processor to resume whatever it was doing before the > interrupt occured. >=20 > > Does it have anything to do with the bios? >=20 > The BIOS is also simply a piece of software, stored > in a chip on the mainboard. It initializes the hard- > ware right after the machine is switched on, and > arranges for the operating system to be booted from > the disk (or from other kind of media if supported). > After the operating system takes control of the box, > the BIOS is not used anymore at all. (There are > certain exceptions, but lets forget about them for > now.) >=20 > Booting is usually a multi-stage process, i.e. first > the BIOS loads a tiny boot loader from the first > sector of the disk (the MBR =3D=3D master boot record), > then the code contained in the MBR loads the > operating system's first stage boot loader and so > on. All of those stages still use BIOS routines > to access the disk. The last stage (in FreeBSD > that's /boot/loader) loads the actual OS, i.e. the > kernel and modules that are required to boot the OS. > The kernel has its own device drivers for disks and > other media, so it doesn't use the BIOS anymore. >=20 > > I told my cousin, that someday he will be a real programmer and that > > even if he will be dealing only with java, html, animation and all > > sorts of high level programming stuffs, >=20 > It should be pointed out that HTML is not a programming > language. ;-) >=20 > > in the spirit of open source (and freebsd of course), it's better > > that he knows exactly how a program interacts with the physical > > computer. >=20 > Well ... It depends. As a high-level programmer, it > is good to know how machine code works and how the > compiler generates it, because it also enables you > to write more efficient programs. That's especially > true for kernel source and device drivers. >=20 > On the other hand, both processors and compilers > become more and more complex and advanced, and newly > designed higher-level languages (such as Python) > increase the "distance" between machine code and the > source code that people write, so there is less > relationship. >=20 > Therefore I think that nowadays it is more important > to learn software design, how to develop efficient > algorithms, learn a bit about computational complexity > (for example, when and why is quicksort faster than > bubblesort) etc. >=20 > At university there was a teacher who said that you > should learn as many different programming languages > as possible, at least one of every kind, i.e. one of > the "classical brace languages", such as C, at least > one object-oriented language (e.g. Smalltalk, Eiffel), > one functional language (Haskell or OCaml), one > assembly language (no matter which one) and so on. > The more the better. >=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 > "With sufficient thrust, pigs fly just fine. However, this > is not necessarily a good idea. It is hard to be sure where > they are going to land, and it could be dangerous sitting > under them as they fly overhead." -- RFC 1925 --=20 Mark Jayson Alvarez mjalvarez@fastmail.fm --=20 http://www.fastmail.fm - Accessible with your email software=0D or over the web
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1182435356.26688.1196346301>